Defect or change? The line is the acceptance criteria
Every module is submitted with acceptance criteria written before the build. That document, and not anyone's memory of a conversation, decides who pays.
| What happened | What it is | Who pays |
|---|---|---|
| The module does not do what its criteria say | Defect | Us — fixed free, including for 30 days after final delivery |
| It does what the criteria say, but that was wrong | Change | You — quoted first, in writing |
| The criteria were silent and we guessed | Defect if our guess was unreasonable, otherwise a change | Discussed before it is billed, never after |
| A third party changed (a gateway's API, a store's rules) | Change | You — quoted in writing first, and we will say if it can wait |
| You want it faster than the quoted date | Change | You, if it is possible at all — usually it is not |
If it is in the acceptance criteria, it is ours. If it is not, you see a price before anyone starts.
How a change order works
The same four steps every time, and they happen in the project room so the record is one place.
- 1
You describe the change — in the project room, not in a call, so there is one version of it.
- 2
We write it as scope and acceptance criteria, the same way a module is written.
- 3
It gets a fixed price, its own delivery date and its effect on the dates after it. All three are stated before you decide.
- 4
You accept or decline in writing. Declining costs nothing and does not affect the rest of the project.
How a change is sized
Changes are priced the same way as the original modules — there is no change-order surcharge, because a change is just a smaller module. The fixed price is in the change order, in writing, before you decide.
| Size of change | How it is handled | Effect on the schedule |
|---|---|---|
| A field, a label, a rule on an existing screen | A revision: no charge within the milestone's two rounds | None |
| A small addition to a module already built | A change order (quick add) | About a week, usually in parallel |
| Something customers use, new to the project | A change order (feature) | One to two weeks, added to the end |
| A whole process the requirements never mentioned | A change order (workflow) | Two to four weeks, added to the end |
Every change order states its fixed price before you accept it. Prices exclude taxes.
Two rounds of revisions per milestone, then change orders
Not every adjustment is a change order. Each milestone includes two rounds of revisions against the accepted requirements — renaming a field, moving a button, correcting copy, tightening a validation rule. A round is one consolidated set of feedback, and it costs nothing.
Rounds beyond the two, and anything that adds, removes or redefines a requirement, are priced as a change order and agreed in writing before we start. We won't charge for a small adjustment because it technically crossed a line, and if we think something is a change we say so before doing the work, not after.
The reason to be explicit about this is that the opposite practice is common: a shop that bills every small thing teaches you not to ask, and a project where the client has stopped asking is a project heading for a bad handover.
Changes before the build starts
Between the requirements document and your acceptance of the proposal, change is free and unlimited. That is what the requirements step is for: the document is deliberately frozen before pricing so that arguing with it costs nothing.
If the requirements change substantially after a proposal is issued but before you accept, the proposal is simply reissued. There is no charge for that, and no pressure to accept the first one.
Change is free until you accept. Afterwards it is quoted, never assumed.
Questions
Do you charge for a change order itself?
No. Writing and pricing a change order costs nothing, and declining one costs nothing. You pay only for a change you accept in writing, priced the same way it would have been if it had been in the original proposal.
What if we disagree about whether something is a defect?
The acceptance criteria decide it. They are written before the module is built and are visible to you in the project room throughout, so the question is a matter of reading a document rather than of recollection. Where the criteria are genuinely silent, we discuss it before anything is billed.
Will a change push my delivery date?
Usually yes, and the change order says by how much before you accept it. Small additions often run in parallel and move nothing; anything feature-sized or larger is added to the end of the schedule rather than squeezed into it, because compressing a plan is how dates get missed.
Can I add a module later instead of changing this one?
Yes, and it is often the simpler route. A new module gets its own fixed price in writing and can be scheduled whenever you like, including after the current project is handed over. If you expect a steady flow of work, ask about a monthly plan on the call.
Also worth reading
- How a project runs Requirements, proposal, fixed price and date, milestones, sign-off, handover.
- Outside India How invoicing, tax and payment work for a client outside India: pay in your own currency by international card or bank transfer, with every tax shown on the proposal before you accept.
- What we build Web apps, mobile apps and internal tools, at a fixed price agreed in writing.