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.

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.
More from the studio.
- 15 October 2025Product
Designing products for India and the UAE
Building for India and the UAE means designing for many languages, scripts, payment habits and network conditions at once. Here is what we have learned about getting it right for these markets.
7 min read - 29 July 2025Design
From Figma to production without the handoff pain
The gap between a design file and shipped code is where quality leaks out. Here is how we keep design and engineering in step so the built product matches the intent.
6 min read - 6 May 2025Strategy
Build custom software or buy off the shelf
The build versus buy decision shapes your costs for years. Here is the framework we use to decide, the questions that actually matter, and the trap of building what you could simply buy.
7 min read

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.