Fixed-Scope Product or Open-Ended Agency? How to Decide

A long run of small yeses

Picture a website project quoted at ₹80,000 and invoiced at ₹1,40,000. Hardly ever is there one large mistake behind a gap like that. There is a long run of small yeses. In week two the client asks whether the gallery can also play video, and the developer says yes. In week four, prices need to show in Hindi as well, and the answer is yes, quickly. In week six the content arrives late and the developer has moved on to another job, so restarting costs a day. In week nine the enquiry form needs to reach three people. Each yes is reasonable by itself. None was priced, because the quote never said what the original number covered.

That is scope creep, and it has a few repeatable mechanisms. This article names them, shows how each way of buying a website or app moves the risk, says honestly where a fixed-scope product is the wrong tool, and ends with nine lines that put a boundary round any project, whoever builds it. The Dwize facts are from its published pricing and Suite pages. Platform and procurement facts carry links and stand as of 3 October 2026.

How scope grows without anyone deciding it

Five mechanisms do most of the damage, and none needs bad faith from anyone.

The first is nouns without numbers. “A gallery”, “a booking page”, “an admin panel”: each noun hides a range of effort from an afternoon to a month. A quote that lists nouns can be satisfied by the smallest version while the buyer imagines the largest.

The second is yeses without prices. The first unpriced yes sets a precedent. By the third, both sides treat extras as free, and the vendor’s bill arrives in one lump at the end.

The third is dependencies on you. Copy, photographs, logo files, approvals, and for a store the KYC paperwork for a payment gateway. When these arrive late, the vendor’s schedule slips and the cost of restarting lands somewhere. If the contract is silent, it lands on whichever side argues better.

The fourth is billing that follows time. When payment depends on hours and there is no ceiling, the vendor’s incentive to finish early is weak. This is not an accusation. It is how the arrangement is built, and the Government of India’s procurement manual lists overrun of time and cost as a major risk of time-based contracts.

The fifth is rules that move under the project. An app is never finished the day it launches. Google Play’s target API policy says that from 31 August 2026 new apps and updates must target Android 16 (API level 36), and a developer can request an extension to 1 November 2026. Existing apps must target Android 15 or higher to stay available to new users on newer Android devices. So even a one-line fix to a year-old app now means rebuilding it against the newer level, and an app that nobody touches for long enough falls out of reach of new users. Whose job that is, and whether it is priced, depends on what the contract says about the year after launch.

Who carries the risk under each way of buying

The Department of Expenditure’s procurement manual for consultancy services, second edition, 2025, is written for government buyers, but its logic transfers to a clinic or a factory. It tells buyers to use a fixed-price contract wherever feasible, since a fixed price for a fixed scope is easy to administer when payments are tied to clearly specified deliverables. It keeps time-based contracts for work whose scope or length cannot be specified. And it names the failure of each. Under a fixed price the supplier may be tempted to trim quality and scope, because payment is not linked to effort. Under time-based billing the risk is overrun of time and cost, because payment follows time. The remedies are practical: written acceptance criteria and payment against acceptance for the first, and an upper limit on total payments for the second.

Mapped to the choices an MSME actually has:

A fixed-scope product sits at the top of that table because the scope is written before you arrive and repeats across customers. You are not negotiating the boundary, you are reading it. That is the whole claim for productised work. It does not make a product better than bespoke work. It makes the risk easier to see.

What a fixed boundary costs you in flexibility

A fixed boundary is a trade, and the trade should be named. Dwize’s Care Year includes 12 content updates a year, each live within 2 business days of receipt. The pricing page says structural rebuilds and out-of-scope work are quoted separately. If your catalogue changes weekly, twelve updates is a ceiling and you should ask how ongoing changes are priced before you sign. The same page says your brand, domain, content, customer data and agreed exports remain yours, while Dwize retains the underlying platform code unless a Suite contract states otherwise. For many owners that is an acceptable arrangement, because they want a site operated and not a codebase to manage. For an owner who wants to hand the code to another developer next year, it is a reason to read the handover terms closely or to look at bespoke work.

Where bespoke work is the right answer

Some needs are not products. A manufacturer onboarding fifty to five hundred vendors with document workflows and payment-release approvals, a distributor with tiered dealer pricing and credit-period tracking, a multi-doctor clinic with prescriptions and billing: each has roles, approvals and integrations whose real scope a standard package would hide. Dwize Suite exists for these. It starts from ₹14,99,000 a year, and its published first-year bands, GST inclusive, are ₹15 to ₹30 lakh for manufacturing systems, ₹18 to ₹35 lakh for B2B distribution, ₹20 to ₹40 lakh for clinic operations and ₹16 to ₹28 lakh for field-service dispatch. A scoping call leads to a fixed-price one-page proposal within seven business days, the build runs 6 to 24 weeks, and the year after launch follows the same eight covenants as every other Dwize product. Per the Suite page, source code, schema, deployment configuration and runbooks ship to you at year-end if you decide not to renew, while the Dwize platform layer beneath the custom code remains Dwize-licensed.

Suite is also a high floor. If what you need is a ₹3 lakh internal tool, the right buyer is a small agency or a freelancer on a fixed or capped contract, and the nine lines further down apply to them in full. Dwize’s contact page says that if it does not fit, it says so plainly.

If you are moving between the two, the Suite page says a productised year converts to a Suite engagement with a 25 per cent credit from the remaining year, and a settled bespoke system can come back to a standard product.

Nine lines that bound any project

These work for Dwize, for a freelancer in Jaipur and for an agency in Bengaluru. A scope is bounded when a stranger could read it and say whether a given request is in or out.

1. Deliverables as counts and names: eight pages listed by title, two forms, English and Hindi, three integrations. Not nouns.
2. Exclusions in writing: copywriting, photography, SEO, ads, data migration, third-party fees.
3. What you supply and by when, and what happens to the date and the price if it arrives late.
4. Revision rounds: how many, and what counts as one (one consolidated list of feedback, not twelve messages).
5. Acceptance: the list of checks that define done, who signs, and how many days you have to test.
6. Change requests: anything outside lines 1 to 3 gets a written price and a date effect before work begins.
7. A cap on total spend for any time-based work, with a review when it is reached.
8. Payments tied to accepted stages, not only to calendar dates.
9. After launch: who maintains it, for how long, what is covered, including yearly platform and store-rule updates for an app, and the price when that period ends.

A change request does not need to be formal. This one is illustrative:

Change 3. Request: Hindi versions of the three service pages. Not in original scope (English only, eight pages). Price: ₹9,000 plus GST. Effect: launch moves from 14 November to 21 November. Reply “approved” to proceed.

The rule behind that note is short. A yes on WhatsApp is not a change order unless it carries a price and a date. Keep the thread, because it is also the record of what was agreed.

Line 5 is the one most often left vague, and it is what makes a fixed price safe for the buyer. A vendor paid on delivery needs “delivered” to mean something, or the price quietly shrinks the work. For a small-business website, a workable acceptance list is short:

• every page in the deliverables list exists and opens on a mid-range Android phone over a mobile connection
• each form reaches a named inbox or WhatsApp number, tested by you and not by the vendor
• phone, WhatsApp and map links open the right app
• the domain, hosting and analytics accounts are in your name and you can log in to each
• the business name, address and GSTIN are right wherever they appear, and the legal name matches the GST portal

Sign it off in writing when the list passes, and not before.

Dwize’s own boundary is stated in numbers in the same spirit: 12 in-scope content updates, 2 business days from receipt to live, and an exit path handled in writing if the fit is wrong in the first 30 days (covenants 02 and 07 of the Care Year).

How to decide this week

Write your need in two sentences, with no product names. Then ask whether it sounds like something other businesses like yours also need or something specific to how you work. If it is common, ask a product vendor for the written scope and the price of the year after launch. If it is specific, ask two bespoke vendors for a fixed-price proposal or a capped time-based one, and send both the nine lines above. Compare the answers, not the portfolios.

If you want a straight answer on which side of the line yours falls, send Dwize the two sentences. We will tell you whether Site, App, Store, Brand, Suite or somebody else is the sensible next step.