Terms of service

1.1The parties

Awiztec, we, us

Awiztec Technologies, a software development practice based in Kozhikode, Kerala, India.

You, the client

The organisation named on the quotation, and anyone it authorises to instruct us on the project.

1.2The documents

Quotation

The priced offer against a written scope, with its own validity period.

SOW

The statement of work: the document that defines what is being built, in what stages, on what dates.

Deliverables

The software, source code, configuration and documentation produced for you under the SOW.

Change note

A written amendment to the SOW, stating a price and a schedule impact, approved before the work in it begins.

1.3When these terms bind

Accepting a quotation, signing a SOW, or paying an advance invoice accepts these terms for that engagement. They are not a click-through: nothing on this website creates a contract, because there is nothing on it to buy.

2.1A quotation prices a scope

Every quotation is issued against a written scope and cannot be read apart from it. A price without its scope is not a quotation; it is a number.

2.2Validity

A quotation is valid for the period stated on it. After that it may be revised — usually because a dependency, a rate or our availability has moved, not as a negotiating position.

2.3Published prices are floors

3.1The SOW is authoritative

Where the SOW and anything else disagree — a call, an email, a slide, a sentence on this website — the SOW governs. Anything not written in it, or in an approved change note, is out of scope.

3.2Silence is not inclusion

A requirement the SOW does not mention is not implied by it. This cuts both ways and is meant to: it is also why we will not later claim that something the SOW does describe was somehow outside it.

4.1Written, priced, and before the work

Changes to scope are handled by change note: what it is, what it costs, what it does to the schedule. Nothing outside the agreed scope is built before you approve one, and small changes already inside the scope are simply done.

4.2The effect on dates

An approved change note replaces the affected dates in the SOW. A project cannot absorb new requirements and keep its original delivery date; where both matter, the priority-delivery terms in the delivery policy apply.

5.1Included cycles

Each milestone includes the number of review cycles stated for your plan. Cycles beyond that are billed at our standard rate, quoted before they are used.

5.2What a cycle covers

Refinement of what was agreed. Restructuring a layout, redesigning a workflow, or changing an interaction model is a new requirement rather than feedback, and goes through section 4. The delivery policy sets this out in full.

6.1What we rely on you for

• Timely decisions and approvals from someone empowered to give them.
• Access to environments, repositories, credentials and third-party accounts.
• APIs, endpoints and data that are ready when the work reaches them.
• Content, assets and licences that are yours to provide.

6.2The timeline safeguard

7.1Named integrations only

Third-party integrations are in scope when the SOW names them. An integration nobody named is a change note, because the cost of one is almost entirely determined by the API on the other side of it.

7.2What we cannot warrant

We are not responsible for a third-party service failing, changing its API, deprecating an endpoint, rate-limiting you, or going out of business. We will tell you what a change costs to absorb, and absorbing it is a change note.

7.3Licences and fees

Subscriptions, API fees, app-store fees and licences for third-party services are yours, billed to your accounts. We will not front them, because an invoice for someone else's SaaS bill helps nobody.

8.1Defects are fixed

A reproducible failure of an in-scope feature to behave as the SOW says it should is a defect, and is fixed at no charge within your plan's warranty window.

8.2Enhancements are quoted

A preference about in-scope behaviour, or a behaviour the SOW does not specify, is an enhancement and goes through section 4. The distinction is the SOW, not the size of the change.

8.3Acceptance

A milestone delivered for review is deemed accepted if no feedback arrives within 3 business days. Tell us you need longer and you have longer; what the clause prevents is the next milestone being built on top of an unreviewed one.

9.1Where it runs

Unless the SOW says otherwise, deliverables are deployed to infrastructure you own, under accounts in your name. This is deliberate: it is what makes the handover real rather than ceremonial.

9.2What deployment includes

Getting the system running on your target environment, with documented steps and configuration. It does not include designing your infrastructure, building a CI/CD pipeline, or setting up monitoring, unless the SOW names those — see the exclusions in the delivery policy.

10.1Named in your SOW

The devices and breakpoints in scope are named in your SOW. Where responsive behaviour is not specified, it is quoted as part of the estimate rather than assumed.

In practice most projects are responsive and are quoted that way; an internal tool used only on desks in one office sometimes is not, and it would be dishonest to price every project as though it were. The clause exists so that the answer is written down before the build rather than argued about after it.

11.1The window depends on your plan

After delivery, in-scope defects are fixed at no charge for the warranty period attached to your plan. The window is a property of the plan rather than a single global figure, and it is stated per plan on the plans page and in your SOW.

11.2What the warranty covers

Defects as defined in 8.1, in the deliverables as delivered. It does not cover changes you or a third party make to the code afterwards, failures caused by a third-party service, infrastructure you have altered, or enhancements.

11.3After the window

Support beyond the warranty window is available as a retainer or on a time-and-materials basis. It is not automatic, and no invoice will ever appear for it without you having agreed to it first.

12.1Milestone billing

Projects are invoiced against the milestones in your SOW, on the standard four-stage split set out in the delivery policy. The first milestone is invoiced as an advance and work begins once it is settled.

12.2Terms

• Invoices are payable within 7 days of issue.
• All amounts are exclusive of taxes, which are applied at the prevailing rate.
• Bank charges and currency-conversion costs on an international transfer are the payer's.
• Unpaid invoices may pause the engagement, and the timeline moves by at least the length of the pause.

12.3Service-plan fees

Where an engagement runs on a service plan, the plan fee and the development cost are independent components. Paying for a plan does not buy development hours, and paying for development does not include a plan.

13.1Practical ownership from the first commit

You get the repository from the start. Work happens in your repository or in one transferred to you, the deploy steps are documented, and nothing needed to run your product lives only with us. If you decide mid-project to take it in-house, there is nothing to extract from us first.

13.2Formal assignment completes on full payment

13.3What stays ours

Our general know-how, and any pre-existing tooling, libraries or internal components we bring to the project. Where such a component ends up in your deliverables, you get a perpetual, irrevocable licence to use, modify and distribute it as part of them — so nothing we own can become a reason you need us later.

13.4Third-party components

Open-source and third-party components remain under their own licences, and we use permissively licensed ones. Anything with an obligation that touches your product is flagged during the build rather than found in an audit.

13.5Portfolio use

We will ask before naming you or showing your work publicly, and we will not do it if you say no. Where consent has not been given, a case study describes the work without identifying the client — which is how the case studies on this site are written today.

14.1Both directions

Each side keeps the other's non-public information confidential, uses it only for the engagement, and does not disclose it without permission. That covers your business information, your data, your roadmap — and our quotations, rates and internal material.

14.2It survives the engagement

This obligation outlives the project and the termination of these terms. We will also sign your own NDA on request, before the first call if you prefer.

14.3The usual carve-outs

Information that is already public, that was already known without obligation, that is independently developed, or that must be disclosed by law or a court — in which case the other side is told, unless telling them is itself unlawful.

15.1Capped at fees paid

Our total liability arising out of an engagement is limited to the fees you have paid us for it. This is the standard position for work of this size, and it is stated plainly rather than buried: a project priced in thousands cannot carry unlimited exposure.

15.2Excluded losses

Neither side is liable for indirect or consequential loss: lost profit, lost revenue, lost data, lost goodwill, or business interruption.

15.3What is never excluded

Nothing here limits liability for fraud, for wilful misconduct, or for anything the law does not permit to be limited.

15.4Your own obligations

Backups, regulatory compliance of your business, and the lawfulness of the data you ask us to process remain yours. We will tell you when something looks wrong; we cannot be the control that catches it.

16.1Either side, in writing

Either party may terminate an engagement by written notice. Work completed to the termination date is billed pro-rata, milestones already invoiced remain payable, and the advance is not refundable. The cancellation page sets this out in full.

16.2What survives

Confidentiality, the payment obligations already accrued, the intellectual-property terms, and the limitation of liability all survive termination.

17.1Indian law

These terms and every engagement under them are governed by the laws of India.

17.3Talk first

Before either side escalates anything, we talk. Almost every dispute in work of this kind is a disagreement about what was in scope, and the SOW usually settles it in one call.

18.1Your engagement keeps the terms it started on

We may revise this page. A revision applies to engagements that begin after it — an active project runs on the terms in force when its SOW was signed, and no edit to this page changes what you agreed to.

19.1Where to ask

Questions about any clause on this page — before signing, ideally — go to contact@awiztec.com. A clause you do not understand is worth an email; asking about it is a good sign in a client, not a difficult one.