Delivery
Delivery & engagement policy
What happens between signing and handover, in the order it happens. This is the working detail behind the terms of service — the same process every engagement follows, whichever plan it runs on.
On this page
Section 1
How an engagement starts
Six steps, and no work begins before the last of them. Nothing here is a formality: each step exists because skipping it is what makes a project go wrong later.
1.1The sequence
- A scoping call. What the business needs to change, who is involved, and what constrains it.
- A written scope. What is being built, in enough detail to price it, with the risky parts named separately rather than averaged into the total.
- A quotation against that scope, with its own validity period.
- A statement of work, once the quotation is accepted. This is the document that governs the project.
- The advance invoice, covering the first milestone.
- Kickoff. Access, environments and the first milestone's alignment.
1.2The SOW is the authority
Where the statement of work and anything else disagree — a call, an email, a slide, a line on this page — the statement of work wins. That is the point of having one, and it is also the protection it gives you: nobody can add to your project by remembering a conversation differently.
Section 2
The delivery team
2.1Who works on your project
A standard engagement runs with one dedicated developer on the build and a project manager who is also a developer. The second role is not an account manager: whoever scopes your project is one of the people building it, and there is nobody between you and them.
2.2Adding people
Additional developers or specialists are added only by mutual written agreement, and doing so affects both cost and timeline. More people on a project that is already late usually makes it later; where extra capacity genuinely helps, we will say so and price it.
2.3Working hours and contact
The work is remote by default, on Indian business days, with calls scheduled around your hours rather than ours. Day-to-day questions go to the project channel; anything that changes scope, price or a date goes in writing.
Section 3
Milestones and billing rhythm
A project is invoiced against four milestones. The percentages are the standard split; your SOW states the amounts.
3.1The four milestones
| Milestone | Share | What it covers |
|---|---|---|
| Kickoff & alignment | 20% | Advance. Reserves the capacity, and covers the scoping already performed. |
| Core feature implementation | 30% | The primary flows working end to end. |
| Feature completion & UAT ready | 30% | Everything in scope built and ready for your acceptance testing. |
| Final handover & sign-off | 20% | Deployment, documentation, credential transfer, sign-off. |
3.2Payment terms
Invoices are payable within 7 days of issue. Amounts quoted are exclusive of taxes, which are applied at the prevailing rate.
Delayed payment may pause work
If an invoice goes unpaid, we may pause the engagement until it is settled, and the timeline moves by at least the length of the pause. This is stated plainly because it is the one consequence in this document that a client can trigger without meaning to — an invoice sitting in an approvals queue has the same effect as a decision not to pay it.
Section 4
Review cycles
4.1What a cycle is
Each milestone includes a set number of review cycles: you look at what was built, send consolidated feedback, and we refine it. The number depends on your plan — one per milestone on Starter, two on Standard, and more on the higher plans. The plans page states it per plan.
Consolidated matters. Feedback arriving in six messages over four days costs more of a cycle than the same feedback arriving once, because each round of changes has to be re-tested.
4.2Refinement, not redesign
A review cycle covers refinement of what was agreed: copy, spacing, states, validation rules, the behaviour of a control. It does not cover changing what was agreed.
These three are new requirements, not feedback
Restructuring a layout, redesigning a workflow, and changing an interaction model are new requirements. They are perfectly reasonable things to want — they are simply not free, and calling them feedback is how a fixed-price project quietly stops being one. They go through section 5.
Section 5
Change requests
5.1A written note, before anything is built
Anything outside the agreed scope gets a written change note stating what it is, what it costs, and what it does to the schedule. You approve it or you do not, and nothing is built either way until you have.
Small things already inside the agreed scope we simply do; there is no note and no charge for those. The note exists so that “can we just…” never becomes an argument at the end of a project.
5.2Approved changes join the SOW
An approved change note amends the statement of work and is billed against the milestone it lands in, or separately if it arrives after the last one.
Section 6
What we need from you
Four things, and they are the four that most often decide whether a project lands on its original date.
6.1The list
- Decisions. One person who can settle a question without convening a committee — worth more to a timeline than any tooling choice we make.
- Requirements that hold still. Changing them is allowed; it goes through section 5.
- Access. Environments, repositories, credentials and third-party accounts, at kickoff rather than when they first block something.
- APIs and data that are ready. If an integration depends on an endpoint that does not exist yet, that is the critical path.
6.2The timeline safeguard
A delay on your side moves the date, and costs you nothing
Where work waits on an approval, an access grant or an API that is not ready, the timeline extends by the length of the wait, automatically and without penalty. There is no charge for the wait itself. What there cannot be is an original delivery date that survives it.
Section 7
Acceptance
7.1Deemed acceptance after 3 business days
When a milestone is delivered for review, it is deemed accepted if no feedback arrives within 3 business days. This is not a trap and it is not a way to close a milestone you are unhappy with: tell us it needs longer and it gets longer. What the clause prevents is a delivered milestone sitting unreviewed for a month while the next one is built on top of it.
7.2Sign-off
Final sign-off follows your acceptance testing on the completed build. It confirms that what was delivered matches the scope — not that you have no further ideas, which is what the next engagement is for.
Section 8
Quality assurance and defects
8.1What counts as a defect
A reproducible failure of something in scope to behave as the scope says it should. Those are fixed, at no charge, within the warranty window for your plan.
8.2What counts as an enhancement
A preference about how something in scope behaves, or a behaviour nobody specified. Those are enhancements. They go through section 5 — including the ones that take ten minutes, because the ten-minute ones are how a warranty window turns into a second project.
8.3How to report one
Steps to reproduce, what you expected, what happened, and where. A defect we can reproduce is usually fixed the same week; one we cannot reproduce is a conversation before it is a fix.
Section 9
Handover
Written for the client who intends to run the product without us. That is what makes keeping us a choice rather than a dependency.
9.1What you receive
- The repository, with its history.
- Documentation of the system: what it does, how it is put together, and where the parts that are not obvious live.
- Deployment steps, verified by following them rather than by remembering them.
- Environment variables and configuration, with what each one is for.
- Transfer of every credential and third-party account created for the project.
9.2And what we give up
Every account, key and token we hold on your systems is revoked at handover, and the pack lists them so you can check rather than trust. If you want us to keep access for a support arrangement, that is an explicit decision recorded in writing, not a leftover.
Section 10
Priority delivery
10.1Compressed timelines
A timeline compressed below what the scope needs is possible on some projects and impossible on others. Where it is possible, it attracts a priority fee, because it means displacing other scheduled work rather than working faster. The fee is quoted upfront with the estimate — never applied afterwards.
10.2What we will not compress
Testing, and the review cycles your plan includes. A build delivered without either is not faster; it is the same project with the slow part moved to after you have paid for it.
Section 11
Excluded unless named in your SOW
Not a list of things we do not do — most of these are things we do, on projects that ask for them. They are excluded by default because each is a body of work in its own right, and quietly assuming them into a fixed price is how a fixed price stops being honest.
11.1The default exclusions
- Performance and load testing, and the tuning that follows from it.
- Post-production monitoring, alerting and on-call response.
- DevOps architecture, CI/CD design and infrastructure redesign.
- Failures of third-party services, and the work to route around them.
- Maintenance and support beyond your plan's warranty window.
- Content, copywriting, translation and data entry.
- Licences and subscriptions for third-party services, which are billed to you directly.
Any of these can be in scope. Ask for it during scoping and it is quoted and named in the SOW, at which point it stops being an exclusion.
11.2Devices and breakpoints
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 either direction. See the terms of service for the full clause.