All writing
Strategy

How we scope a fixed budget project

A practical look at how we turn a vague brief into a fixed price you can plan around, using a short discovery phase, a clear must-have list and a sane way to handle change requests.

Vikram Nair · Founder19 February 20247 min read

Most founders who come to us with a fixed budget have already been burned once. They paid for an estimate, the estimate doubled halfway through, and the relationship soured. So when someone asks us for a fixed price, the real question underneath is: can I trust this number?

The honest answer is that a fixed price is only as good as the thinking behind it. You cannot price what you have not defined. So fixed budget work, for us, comes down to closing the gap between what you imagine and what we will actually build, before anyone signs anything.

Start with a short discovery phase

We almost never quote a full build from a one page brief. Instead we propose a paid discovery phase, usually one to two weeks, where a designer and an engineer sit with you and pull the idea apart.

In that time we do a few specific things:

  • Map the core user journeys end to end, not just the happy path.
  • List every screen and every meaningful state, including empty states and errors.
  • Identify the integrations, such as payments, messaging or a CRM, and check their real limits.
  • Flag the unknowns that could blow up the timeline, like a third party API with poor documentation.

Discovery is cheap insurance. A week of focused work routinely saves us from a wrong estimate that would have cost weeks later. By the end we can hand you a written scope, a set of wireframes, and a price we are willing to stand behind.

Split the scope into must-have and later

The single most useful exercise we run is sorting features into two buckets: must-have for launch, and later. Founders tend to want everything in version one. We push back, gently, because a smaller first release almost always gets to market faster and teaches you more.

A must-have feature is one without which the product cannot do its core job. A later feature is something real users will eventually want, but which the business can survive without on day one. Admin dashboards, fancy analytics, and that second onboarding flow you are unsure about usually belong in later.

If a feature does not change whether someone can complete the main task, it is rarely a launch feature.

This split is what makes a fixed budget realistic. We price the must-have list tightly and keep the later list visible, so nothing is forgotten, but nothing inflates the launch number either.

Build in a buffer, and say so

We add a contingency buffer to every fixed quote, usually around ten to fifteen percent, and we tell you it is there. Hiding a buffer inside inflated line items is the kind of trick that erodes trust. Software has surprises. The buffer is what absorbs the small ones so we do not come back to you over every minor snag.

If the buffer goes unused, that is a good outcome for everyone. It is not a fee, it is a margin for reality.

Handle change requests without drama

No scope survives contact with a real product. Halfway through, you will see a screen and realise it should work differently. That is healthy. The problem is when changes arrive with no process, because then the budget quietly dies.

Here is how we keep it clean:

  • Anything inside the agreed scope, including reasonable refinement, is covered. Moving a button or adjusting copy is not a change request.
  • Anything that adds a new screen, a new integration, or new logic is a change request. We estimate it in hours and cost before doing the work.
  • You decide each time whether to approve it now, defer it to the later list, or drop it.

We keep a simple running log of these decisions so there are no surprises at the end. The point is not to nickel and dime you. The point is that you always see the trade between scope, time and money, and you stay in control of it.

What this looks like in practice

A retail client came to us wanting a full inventory and loyalty platform on a tight budget. Discovery showed that loyalty was the part they were excited about, but inventory was the part they actually needed to open. We scoped a lean inventory tool as must-have, parked loyalty in later, and shipped in nine weeks inside budget. Loyalty came three months on, funded by the revenue the first release brought in.

That sequencing is the real benefit of doing this properly. A fixed budget is not a cage. Done well, it is a shared plan that protects your money and our reputation at the same time.

If you are weighing a fixed price engagement, the best thing you can do before talking to any studio is write down your own must-have list. It will make every conversation that follows far more useful.

Let us build the thing
you keep putting off.

Book a free consultation. Tell us what you are building and we will come back with scope, budget and a realistic timeline.