1. About KARODIAL and these terms
KARODIAL, operated by Avycore Tech Private Limited, provides a website-design catalogue, project-enquiry facilities and services relating to websites, AI-assisted development and Android/iOS applications. These Terms of Service explain the general rules for using karodial.com and discussing or commissioning work through us. Read them with our Privacy Policy and any proposal or project agreement you accept. Browsing a design, creating an account or asking a question does not by itself commission a paid development project.
A paid engagement needs agreement on its commercial details. If you act for a company or another person, you must have authority to make the relevant commitments and share the materials involved. You must be at least eighteen years old to enter a paid project agreement. If you do not accept the website-use terms, do not create an account or submit a service request through the website. These terms do not remove any right or protection that applicable law makes mandatory.
2. Proposals and written project agreements
A written proposal, statement of work or project agreement should identify what will be delivered, who will provide required materials, the fees and taxes, payment milestones, estimated timing, revision allowance and acceptance process. It should also address deployment, ownership or usage rights, source-code handover, support and any recurring costs. A project-specific written term prevails over a conflicting general website term to the extent legally permitted. The final agreed scope should be clear enough that both parties can distinguish an included requirement from an additional request.
A sales conversation, draft estimate, sample screen or chatbot reply alone is not a complete agreement on every commercial detail. Ask for clarification before approving work or making a payment if an important item is missing. We may need to review technical feasibility, existing systems and dependencies before confirming an estimate. An agreement should identify authorised contacts so instructions and approvals do not depend on informal messages from people without authority to change the project.
3. Design catalogue, previews and sample content
Our catalogue presents starting points for discussion, not a promise that every visual element and feature in a live demo is included in every plan. Demonstrations can contain illustrative businesses, people, addresses, prices, products, transactions and testimonials. Those examples are not evidence of real KARODIAL customers, endorsements or completed transactions. Demo forms, shopping carts, account screens and payment pages may be visual examples rather than working production services. Do not submit real payment details, passwords or confidential information into a sample template.
Use KARODIAL's own enquiry or contact facilities to describe your requirements. Selecting a design does not reserve it exclusively, grant ownership of the underlying template or authorise downloading and reselling the catalogue library. A finished project can differ because of your content, licensed assets, agreed functionality and responsive layout. Before commissioning, identify the pages and behaviours you actually need rather than assuming that everything visible across a multi-page demo is automatically part of a standard package.
4. Accounts, authorised users and secure access
Provide accurate account and contact information and keep access to the email address associated with your account. Use only accounts you own or are authorised to operate. Do not impersonate another person, misrepresent business authority or share staff access with an unauthorised user. Google/Firebase sign-in is subject to the provider's authentication process as well as our application controls. Keep your devices and sign-in credentials secure and report suspected unauthorised activity promptly. We may need proportionate verification before changing sensitive account details or disclosing private project information.
Staff and administrative access is restricted to authorised personnel; creating a customer account does not grant those permissions. You are responsible for instructions you validly authorise, but these terms do not automatically make you responsible for every unauthorised action regardless of its cause. Tell us about a suspected compromise so the circumstances can be investigated. Closing an account does not automatically cancel an active project, erase an invoice or settle an outstanding contractual obligation.
5. Development-only service, plans and taxes
KARODIAL provides website and app development within the agreed scope. We do not provide domain registration, hosting infrastructure or email-server services as part of that development engagement. Customers must arrange and pay for those services directly with their chosen providers. Technical setup assistance does not make KARODIAL the infrastructure provider.
Review the confirmed quotation, included features, deliverables and taxes before paying. Where eighteen per cent GST is stated as additional, review the total accordingly. Future catalogue changes do not retrospectively alter an accepted written project agreement.
6. Domain ownership, registration and renewals
The customer is responsible for choosing, registering, owning and renewing the domain through an independent registrar. Domain charges, expiry, recovery, ownership disputes and registrar restrictions are outside our development service. Keep the domain in an account you control. Any agreed DNS configuration assistance does not transfer domain ownership to KARODIAL or make us responsible for registrar operations.
7. Hosting, server availability and infrastructure
The customer must arrange suitable hosting or cloud infrastructure and pay its charges and renewals. KARODIAL is not the hosting company and does not operate or guarantee the customer's server uptime, bandwidth, storage, infrastructure security or provider support. Provider outages, account suspension and expired subscriptions must be addressed with that provider. Our responsibility remains the agreed development work, without excluding responsibility for our own actions under the agreement and applicable law.
8. Email servers, mailboxes and delivery
Business email hosting, mailbox licences, email-server operation, spam filtering and mail delivery are the customer's and the chosen email provider's responsibility. KARODIAL develops the agreed website forms and integrations; this does not include running an email server or guaranteeing inbox placement. The customer must provide valid sender settings and maintain the provider account. Separately agreed configuration assistance does not include ongoing mailbox or server administration.
9. Online payments and payment verification
Where checkout is available, review the order reference, base amount, tax and total before opening the payment interface. Use the legitimate Razorpay checkout and the payment method you are authorised to use. Payment confirmation depends on server-side verification of the matching transaction; a client-side success screen or screenshot alone may not establish that the correct amount was captured. A recorded payment and a project's development stage are different things.
Project stages such as Received, In progress, Completed, Delivered and Canceled describe workflow, not a second payment instruction. If the bank shows a debit but the account has no confirmation, retain the transaction reference and ask support to check before paying again. Do not send card security codes, banking passwords or UPI PINs to our team. Notify us about a suspected duplicate or incorrect charge with enough information to identify it. We will review the transaction and applicable agreement; provider and banking settlement times can affect when a correction or approved refund appears.
10. Requirements, changes and additional work
A useful scope describes deliverables and boundaries, including pages, forms, account roles, integrations, supported platforms and the content each party supplies. A request can be a change even if it sounds small: adding another language, payment flow, admin role, migration, reporting screen or external API can affect several parts of a system. We should assess the impact and agree any additional cost or schedule change before carrying out chargeable work beyond the accepted scope.
Neither party should rely on an ambiguous chat message as an unlimited revision commitment. Keep a written record of approved changes and the version or milestone they affect. Clarifying a requirement already included is different from introducing a new feature, and fixing an agreed defect is different from redesigning an approved page. If there is disagreement, compare the request with the written scope and resolve it before continuing the disputed additional work. Existing obligations and mandatory remedies remain subject to the agreement and applicable law.
11. Client materials, instructions and approvals
You should provide the lawful text, logos, images, business details, product information and other materials identified in the project agreement, in a usable format and within the agreed sequence. Confirm that statements about your business, professional qualifications, prices, offers and customer outcomes are accurate. Our design or development work does not independently verify every factual claim supplied by a client. You must have permission to provide the materials and to authorise their intended publication.
Identify one or more authorised contacts who can consolidate feedback and approve changes. Conflicting instructions from multiple people can cause rework and delay, so resolve them internally before asking us to implement them. Review draft content and links carefully, including telephone numbers, email addresses, legal notices and payment details. Tell us if any item is confidential or must not appear publicly. An instruction to publish should follow review of the agreed release, rather than assuming that a temporary preview or placeholder is ready for real customers.
12. Timelines, dependencies and project communication
Delivery estimates depend on the agreed scope, access to systems, receipt of content, client feedback and the availability of required third-party services. An estimate is not an unconditional promise regardless of those dependencies. The agreement should identify important milestones and explain how delays or changed requirements will be handled. Tell us promptly about an event date, campaign launch or other fixed business deadline before commissioning so feasibility can be assessed.
13. Project records and authorised communication
Where a delay occurs, the parties should communicate its cause, likely impact and a revised plan rather than leave expectations unclear. Waiting for approval, missing credentials or unresolved decisions can interrupt the sequence of work. A project-status label is a summary and does not replace a detailed milestone report or acceptance record. Keep important instructions and approvals in a retrievable written channel. If a project becomes inactive, discuss the remaining work, access and restart arrangements; inactivity alone should not be used to invent a new forfeiture or cancellation term that was never agreed.
14. Revisions, testing and acceptance
The agreement should explain how many review rounds are included, what each round covers and how defects will be reported and resolved. Consolidated, specific feedback is more useful than unrelated instructions spread across several channels. Identify the page, device, steps and expected result when reporting a functional issue. Reasonable testing should consider the agreed user flows, responsive layouts and supported browsers or platforms. It does not mean every possible device, legacy browser or third-party configuration is guaranteed.
A new preference after an approved design may be additional work, while a failure to meet an included requirement should be assessed against that requirement. Acceptance should follow the agreed process; these general terms do not impose an automatic acceptance period merely because a preview link was sent. Publication approval, milestone acceptance and final handover can be separate events. Keep a record of remaining issues and whether they affect release. Any statutory remedy for defective services remains available to the extent it cannot lawfully be excluded.
15. Two-language websites and content responsibilities
Where a plan includes a website in two languages, confirm which two languages, which pages and interface elements are covered, who supplies or approves translations and how updates will be maintained. Bilingual support does not automatically mean that every third-party widget, embedded document, user-generated message or external service has been translated. Layout, fonts and text length can differ between languages, so review both versions on the intended devices. Machine-assisted translation needs human review, particularly for names, prices, technical instructions, professional claims and legal text.
You should approve the meaning of customer-facing statements for your business; an attractive layout does not establish linguistic or legal accuracy. Additional languages or a large translation exercise may require a separate quotation unless included. After launch, changing one language does not automatically create an approved translation in the other. Agree who is responsible for keeping versions consistent. For our own policies, read the available language versions together and contact us if wording appears inconsistent; mandatory rights are not reduced by a translation error.
16. Android, iOS, webviews and app-store review
App development can include a native application, a cross-platform implementation or a webview-based wrapper, depending on the written scope. These approaches have different capabilities and constraints. A website working in a desktop browser does not guarantee identical behaviour inside a mobile app, especially for authentication, file uploads, payments, downloads, permissions and external links. Confirm required native features, operating-system versions and test devices before development. A webview conversion is not a promise of approval by Google Play or Apple's App Store.
Store policies, review decisions, developer-account verification and ongoing platform changes are outside our sole control. The project should identify who owns the developer accounts, supplies store content, approves privacy disclosures and handles submission or resubmission. Store fees and required third-party subscriptions are included only if stated. Your underlying website must be lawful and you must have authority to package it. Ask for a feasibility review rather than assuming any public URL can become a publishable app without changes or additional permissions.
17. AI, Firebase, SMS and external integrations
Projects may involve Google/Firebase authentication, contact forms, SMS acknowledgements, payment gateways, WeBot or other agreed integrations. Each depends on its provider's account requirements, technical limits, availability and terms. AI-generated text, code and chatbot responses can be incomplete or inaccurate and require review. They are not professional legal, medical or financial advice or a guarantee of business outcomes.
Provider API changes or discontinued features can require agreed migration or additional development. SMS delivery depends on network conditions, valid numbers and messaging requirements. Technical access to a sending feature does not authorise unsolicited, unlawful or deceptive communication.
18. Third-party subscriptions and usage charges
An integration subscription included for a stated period is limited to the named plan and period; it is not free lifetime renewal or unlimited provider usage. Confirm activation, renewal responsibility, message charges, app-store fees and usage limits before purchase. Paid plugins and continuing subscriptions remain separate unless explicitly listed as an included development-plan benefit. Such a benefit does not include domain, hosting or email-server services, which customers arrange independently.
19. Ownership, licences and supplied materials
You retain the rights you already hold in materials you supply, and permit their use as reasonably needed to assess and perform the project you request. You must secure necessary permissions for text, trademarks, photographs, videos, fonts, software and personal information. Commissioned deliverable ownership or usage rights, any payment conditions for transfer and the treatment of reusable components should be stated in the agreement. Third-party templates, libraries, plugins and other assets remain subject to their licences; customisation does not convert them into unrestricted property.
Some assets may be licensed for a deployed site but not for standalone resale or distribution. Open-source components can carry notice or other licence obligations that continue after handover. KARODIAL branding and catalogue presentation must not be used to impersonate us. A completed project licence does not automatically grant rights over the entire design library or another customer's work. Discuss portfolio publication separately when confidential information, unreleased products or identifiable customer material is involved; contacting us alone is not consent to publish a testimonial.
20. Source code, deployment and handover
Confirm what “code transfer” or “handover” means for your purchase: source files, build instructions, database export, configuration guidance, administrative access and documentation can be different deliverables. Credentials and private keys should be transferred through an agreed appropriate method rather than embedded in public source archives. Hosting and developer accounts should have a clearly identified owner. Deployment to your hosting requires suitable authorised access and a review of the existing environment; replacing an active site can affect its files, database, email or integrations if the scope is not understood.
21. Deployment access, migration and operational handover
Agree backup and migration responsibilities before a production change. Third-party accounts, licences and platform credentials cannot always be transferred in the same way as source code. Delivery of code does not include every provider's internal system or a licence to redistribute proprietary dependencies. After handover, record who maintains the system and remove temporary development access when appropriate. A project can be technically delivered while additional operational steps remain the customer's responsibility under the agreement.
22. Support, maintenance and future updates
A development fee does not automatically include indefinite maintenance, unlimited content updates, emergency cover or permanent compatibility with every future platform change. The written agreement should identify any included support period, covered issues, contact method and separately chargeable services. Distinguish a defect in the agreed delivery from a new feature, a client edit, a provider outage or an issue caused by an unrelated modification. This distinction should be assessed fairly against the evidence and the scope, not used to avoid a genuine included obligation.
Keep supported software and dependencies appropriately maintained after launch and identify who handles backups, security updates, renewals and monitoring. A hosting subscription and an application-maintenance service are different arrangements. If another developer changes the system, tell us when requesting assistance so troubleshooting can consider the current version. We can discuss ongoing support or a fresh maintenance engagement, but these website terms do not create a service-level guarantee or fixed response time that has not been agreed.
23. Confidentiality, privacy and security cooperation
Use a suitable agreed channel for confidential project materials and identify any handling restrictions before providing them. Do not send passwords, production customer databases, banking credentials or unnecessary identity documents through the public contact form or chatbot. Where access is required, limited-purpose accounts and test data can reduce risk. A customer must have authority to share the personal information supplied for development and must provide appropriate notices for its own products and users. Our Privacy Policy describes karodial.com; it is not automatically a compliant privacy notice for every customer website or app.
A separate processing or confidentiality agreement may be needed for the engagement. Neither party should use the other's confidential materials for an unrelated purpose without appropriate authority. Security also depends on hosting, credentials, configuration, maintenance and third-party services, so no general promise of an unhackable website is made. Report a suspected disclosure promptly and avoid spreading exposed information while investigating it. Specific confidentiality obligations and legally required protections remain subject to the agreement and applicable law.
24. Acceptable use and prohibited activity
Do not use our website or services for unlawful content, fraud, impersonation, harassment, malware distribution, unauthorised access or infringement of another person's rights. Do not bypass access controls, attempt to access non-public customer or administrative records, interfere with normal operation or submit deceptive enquiries. Automated activity must not abuse the service, evade reasonable protections or harvest private information. Do not present sample demo records as proof of real customers or transactions.
You must have authority to request changes to a website, domain, repository or app; access to a public URL does not establish ownership. We may decline a request or take proportionate protective action where there is a genuine legal, security or abuse concern. A restriction affecting paid work must still be considered under the agreement and applicable law. If access is restricted in error, contact support with relevant details. These rules do not prohibit lawful criticism, a good-faith complaint or the exercise of a statutory right merely because it is inconvenient to us.
25. Cancellation, pauses and outstanding obligations
To cancel or pause a project, notify the authorised contact in writing and identify the requested effective point. Cancellation does not create a right to a voluntary refund of development payments. Completed work, committed costs, unpaid contractual milestones and any agreed handover remain subject to the project agreement and applicable law. A Canceled workflow label or account closure does not itself settle balances or reverse a payment.
26. No-refund policy for development payments
Payments made to KARODIAL for development services are non-refundable. We do not offer voluntary refunds for a change of mind, client-requested cancellation, unused project time, delayed client materials or a decision not to publish or use the completed work. Review the scope, selected design, price and exclusions before paying. A concern about an included requirement should be reported for review and correction under the agreement.
This policy does not exclude a refund or other remedy that applicable law requires, nor prevent correction of a verified duplicate or erroneous payment. It does not excuse failure to perform an agreed service or override a pre-existing contractual refund entitlement. Any payment reversal required by law, an existing agreement or a verified transaction error is handled on that basis.
27. Availability, outcomes and limitations
We aim to keep the website and agreed services useful, but maintenance, errors, network failures, provider outages and security incidents can interrupt availability. Catalogue access is not an uptime service-level agreement. A design or development engagement does not guarantee search rankings, revenue, leads, conversion rates, app downloads or business profitability. Those outcomes depend on content, market conditions, customer decisions, marketing and other factors beyond development alone. Accessibility, performance, compatibility and security targets should be specified and evaluated for the actual project rather than inferred from promotional wording.
Third-party links are provided for relevant access or information and do not guarantee the accuracy or safety of everything on another website. We should communicate known material issues affecting contracted work and address them under the agreement. These limitations are explanations of scope and uncertainty; they do not excuse a failure to provide an expressly agreed service or remove statutory guarantees. Tell us about a service problem with a concrete example so it can be assessed and an appropriate remedy considered.
28. Responsibility, remedies and disputes
Any project-specific warranties, support promises and allocation of liability should be stated in the written agreement and remain subject to applicable law. These general terms do not create an arbitrary universal liability cap, exclude every kind of loss or require a customer to give up a non-excludable remedy. Responsibility for a particular issue depends on the agreement, the cause, the parties' actions and the law that applies. Take reasonable steps to avoid increasing a known loss, such as reporting a broken payment flow and pausing an affected campaign while the issue is reviewed.
Keep relevant communications, versions and transaction references so the problem can be assessed fairly. Do not disclose unrelated private customer records merely to support a complaint. We encourage an initial support discussion identifying the issue and requested resolution. If that does not resolve the matter, you retain access to the competent court, consumer forum or other authority available under applicable law. No exclusive arbitration or jurisdiction requirement is created by this paragraph.
29. Changes, applicable law and contacting us
The date above identifies this version of our website terms. We may update them when services, features or legal requirements change. Updates should not retrospectively alter an existing written project agreement unless the parties agree or applicable law requires it. A change requiring additional notice or acceptance should be handled accordingly; editing a public page does not replace a required contractual step. These terms are governed by the laws of India, subject to mandatory protections that apply to you.
The appropriate forum is determined under applicable law, and statutory or consumer remedies are preserved. If part of a term is unenforceable, its effect and the remaining terms must be considered consistently with that law rather than used to remove mandatory protections. For a question, project concern or complaint, write to support@karodial.com or use the Contact page. Include KARODIAL, the relevant project or order reference, a clear description and the resolution requested. Do not include passwords or unnecessary sensitive attachments. Read our Privacy Policy for personal-information handling.