MAKIN 
Scope fails in the gaps, not the specification.
Nobody argues about the listed features. Disputes start over the things each side assumed the other was handling — data migration, content, who tests, who trains the team. Whoever is building, the painful part of a project usually lives in that gap.
Write the exclusions down, awkward as it feels.
Listing what is not included can feel unfriendly at proposal stage. It is still far cheaper to have that conversation before work starts than in week seven with a deadline attached.
Change is normal; unpriced change is not.
Requirements should change — that is how a team learns what it needs. The failure is absorbing changes silently until the schedule quietly breaks. A short written note per change, with its effect on time and price, keeps both sides honest without ceremony.
The assumption list is the real contract.
Attach a list of assumptions to every proposal, each with what changes if it turns out false. It turns a vague worry into a line someone can check before kickoff, which is the cheapest moment to find out an assumption was wrong.
The gaps that cause most disputes
The arguments that sink a project are seldom about the features on the list. They are about work that sits between the two sides, which each assumed the other would do. Before a proposal is signed, give every item below a named owner, even if the answer is ‘not part of this project’:
- Data migration: who exports the old data, who cleans it, and who checks it after import
- Content: copy, photos, product details and translations, and the date each is due
- Accounts and fees: domain, hosting, the WhatsApp Business API, payment-gateway approval and app store accounts, and who pays for each
- Testing: who tests, on which devices, and what counts as finished
- Training: who trains the team, in how many sessions, and who trains the next new joiner
- Other systems: Tally, a marketplace or a courier whose rules neither side controls
- After launch: who fixes problems, for how long, and what counts as a fix rather than a change
Writing exclusions that do not read as hostile
An exclusion reads as unfriendly when it is only a refusal. Pair each one with what happens instead, and it becomes useful information. ‘Photography not included’ invites an argument later. ‘We use the photos you provide; a shoot can be quoted separately’ tells the client what to prepare and what changing it would involve. A few more in the same shape, written as they might appear in a proposal:
- Content entry: you provide the product list in one spreadsheet; we import it once, and later uploads are made by your team from the admin
- Old records: we import the last two financial years; older records stay in the old system, read-only
- Integrations: we connect to the Tally release you run today; an upgrade that changes how it connects is quoted as a change
- After launch: defects found in the agreed period are fixed; new features are quoted separately
An assumption list, with examples
Every estimate rests on assumptions, and most of them are never said aloud. Writing them down turns each one into something both sides can check before work starts. Give each assumption three parts: what is assumed, why it matters to the price or the date, and what happens if it turns out to be false. Some typical entries for a small business project:
- Your team reviews each delivered screen within three working days; longer reviews move the launch date by the same amount
- Product data arrives in one format, with one row per variant; cleaning data from several formats is quoted separately
- The current website’s hosting login is available in week one; without it, old addresses cannot be redirected
- One person on your side can make decisions; if several people must agree on each point, the schedule allows for that explicitly
A change note in five lines
Changes are cheap to agree when they are small and written down, and expensive when they pile up unspoken. Suppose, as an illustration, that halfway through a website build the owner asks for every page in Hindi as well. That is a reasonable request and a real change: translation, a language switch and twice as many pages to test. Written as a change note, it adds a stated number of days and a stated price, and the owner decides with both in front of them instead of discovering the cost at the end.
A change note needs no form and no meeting. Five lines, sent by email or WhatsApp and acknowledged in writing, are enough:
- What was asked for, in the client’s words
- Why it came up, so the reason survives fading memories
- The effect on the schedule, in days
- The effect on the price, or ‘no change’
- Who approved it, and when
Deciding what done means before you start
The last gap is the end of the project. If nobody has said what ‘finished’ means, the final weeks fill up with items each side files differently: a defect to one, a new request to the other. Agree acceptance before work starts, while nobody has a deadline to defend:
- For each feature, a short test: who does what, and what should happen
- The devices and browsers it must work on, such as a recent Android phone, an iPhone and a desktop browser
- The test data to use, supplied by the client where it is their real data
- A sign-off window, after which delivered work counts as accepted
- A plain rule for telling a defect (it does not do what was agreed) from a change (it does what was agreed, but you now want something else)
How we put this into practice
Our proposals carry a written scope note: what is included, what is excluded, what we assumed and what changes if an assumption breaks, with a fixed price for that scope. The templates we hand every new client include the scope note and the handover document, and a two-week discovery sprint is how a larger project gets its scope written down before anything is priced.
For a smaller decision, a Tech Strategy Consultation from ₹3,000 gives you a current-state audit, a build-versus-buy recommendation and a risk register in two sessions. The full set is on the consulting packages page.