One Number, Agreed Before Anyone Writes Code
You know the budget before you commit. If the work takes longer than we estimated, that is our problem and your invoice does not move — which is exactly why we spend real effort on the scope first.
- Milestone payments tied to working software
- Written change requests, approved before starting
- Overruns come out of our margin, not your budget
When Fixed Price Is Right — and When It Is Not
Fixed price is a good deal for you when the work can be described. When it cannot, it quietly becomes a worse deal than hourly, and we would rather tell you that now.
Suits a fixed price
- A first version whose screens and core flows you can list
- A defined module added to something that already exists — payments, reporting, an admin panel
- Rebuilding a known thing on a new platform, where the behaviour is already settled
- An integration with a documented third-party service
- A design and clickable prototype phase, which is naturally bounded
- Work with a hard external deadline, such as an event or a compliance date
Does not suit a fixed price
- Research projects where the output is a finding rather than a feature
- Products where the requirements genuinely change every fortnight in response to users
- Anything depending on a third-party system nobody can inspect until work begins
- Open-ended optimisation, where “better” has no agreed finish line
- Long programmes of work where the roadmap past month two is honestly unknown
- Situations where you want to change direction weekly and value that freedom
If your project sits in the right-hand column, a dedicated team is almost always cheaper in practice, because you stop paying for contingency on work nobody can describe yet. Compare the models on how we work.
How We Arrive at the Figure
A fixed price is only safe for both sides if the scoping is real. This is the work that happens before you receive a proposal, and it is free.
1. A conversation, not a form
Thirty to sixty minutes on what the product is for, who uses it, what has to be true for it to be worth building, and what you are prepared to leave out of version one. The last question is the one that decides the number more than any other.
2. Written scope in plain language
A list of screens, user roles, integrations and behaviours, described so a non-technical reader can check it. Where something is ambiguous we write the assumption down explicitly rather than resolving it quietly in our own favour. You read this and correct it before any number is attached.
3. Estimated in pieces, not in one guess
Each screen and each behaviour is sized separately by the engineers who would build it, then design, testing, store submission, project management and a contingency band are added on top. An estimate built from thirty small judgements is far more reliable than one built from a single large one.
4. Risky parts carved out or flagged
If one piece is genuinely unpredictable — an undocumented legacy API, a regulator whose requirements are not yet published — we either price it separately once it is understood, or we name the assumption in the proposal. Burying that risk in a padded total is the more common approach and it is worse for both of us.
5. One proposal, one number, the assumptions attached
You receive the scope, the price, the milestone schedule, the timeline and the list of assumptions in one document. The price does not change unless the scope does, and the mechanism for changing the scope is written into the same document.
What You Pay, and When
Every milestone is attached to something you can open, install or click. None of them are attached to a date alone.
On signature
Books the team into the schedule and covers kickoff, environment setup and the start of design. This is the only payment that is not tied to a deliverable, for the obvious reason that nothing has been built yet.
Design sign-off
Released when you have approved the screen designs and a clickable prototype. At this point you have seen the whole product before a line of production code exists, which is the cheapest possible moment to change your mind.
Mid-build demo
Released against a working build with the core flows functioning, installed on your own device. Not a video, not a walkthrough on a call — something you hold.
Delivery
Released on final delivery: the complete build, tested, submitted to the stores if applicable, with the repository, documentation and credentials handed over. IP transfers in full at this point.
The split adjusts for longer builds — a six-month project usually gets monthly milestones rather than four large ones, so neither side is ever far out of pocket. A defect warranty runs after delivery, during which anything that does not behave as the scope described is fixed at no cost.
The Change Request Process
Scope moves on most projects. Fixed price does not mean nothing can change; it means changes are visible, priced and agreed instead of appearing on a final invoice.
You raise it
On a call, in an email, in the project board. However it arrives, it gets written into the change log the same day so nothing depends on somebody remembering a conversation.
We price it
Within two business days you get the cost, the schedule impact, and what it knocks out of the way if anything. Some changes reduce the total, and we say so when they do.
You approve or decline
In writing, one line is enough. Declining costs nothing and is a perfectly normal outcome. Work never starts on an unapproved change, and no change is ever assumed.
The total updates once
The contract value and delivery date move by the agreed amount, recorded in one running document. There is never a surprise reconciliation at the end of the project.
Small things we simply do. Renaming a label, adjusting spacing, reordering a list, changing copy — raising paperwork for those would cost everybody more than the work itself. The threshold is judgement, not a stopwatch, and it errs in your favour.
If It Takes Longer, That Is Our Problem
This is the entire value of the arrangement. It is worth being precise about where the line sits.
Our Estimate Was Wrong
A screen turned out to be harder than it looked. The third-party library behaved differently in practice. An engineer needed three attempts at the data model. Testing found more than expected. A store rejection needed a resubmission. In every one of these the extra hours come out of our margin, the delivery date holds where we can make it hold, and your invoice is exactly what the proposal said.
You Asked for Something New
A user role the scope did not contain. A platform that was not in the agreement. A redesign of a screen you already signed off. An integration nobody mentioned during scoping. A regulator adding a requirement mid-project. These are priced, shown to you and approved before any work starts — and you are free to say no.
The Grey Middle
Sometimes the scope was simply ambiguous and both readings were reasonable. Our rule is that ambiguity in a document we wrote is resolved in your favour, up to the point where it would materially change the size of the project. Beyond that we bring it to you with both readings laid out and decide it together, with the reasoning on record.
The Lowball
Quoting deliberately low, then making the margin back through change requests on work that was always going to be necessary. It is common enough that experienced buyers expect it. If a quote you are holding is dramatically below the others, ask what happens when it overruns — and get the answer in writing.
What You Have at the End
The software
- A tested build, live in the stores or deployed to your hosting
- Source code in a repository in your name, with its full history
- Automated deployment, so the next release is routine
- Admin access to everything the product runs on
The paperwork
- Full IP transfer on final payment
- Setup and deployment documentation another developer can follow
- A written list of known limitations and deliberate exclusions
- Design files and the source assets behind them
What happens next
- A defect warranty covering anything that does not match the agreed scope
- An optional maintenance retainer if you want us watching it
- A quote for version two, if and when you want one
- No obligation to keep us at all, and no lock-in that would make leaving hard
Fixed-Price Questions
How are the payments structured?
A deposit to begin, then payments released at named milestones, with the final portion due on delivery. On a typical build that is 30 percent to start, 20 percent at design sign-off, 25 percent at the mid-build demo and 25 percent on delivery. Every milestone is tied to something you can open and check for yourself, never to a date on a calendar.
What if we want something changed after the scope is signed?
You raise it, we write it up as a change request with a cost and a schedule impact, and you approve or decline it before anything begins. Small changes that cost us nothing get absorbed without paperwork, because raising a change request over a button colour helps nobody. What never happens is work being started on the assumption that you will approve it afterwards.
What happens if the build takes longer than you estimated?
We absorb it. That is what fixed price means, and it is the reason we scope carefully before quoting rather than during the build. If we misjudged the work, the extra hours come out of our margin and your invoice does not change. The single exception is work that is genuinely outside the signed scope, which becomes a change request rather than an overrun.
Do you pad fixed-price quotes to protect yourselves?
There is contingency in every fixed price, and anyone who tells you otherwise is either inexperienced or not being straight with you. What we do not do is hide it. Where part of the scope is genuinely uncertain we either carve it out and price it separately once we know more, or we write down the assumption the number rests on so you can challenge it before signing.
Can we cancel partway through?
Yes. You pay for the milestones already delivered plus any work in progress at that point, and we hand over the code, the credentials and a written statement of exactly where things stand. There is no termination penalty. The repositories and accounts are already in your name, so there is nothing for us to release.
Can an MVP be fixed price when we are still learning what it should do?
Usually yes, provided we fix the scope rather than the vision. We agree a specific set of screens and behaviours for version one, build exactly that, and deliberately keep the parts you are unsure about out of it. If instead the entire product is still a question mark, fixed price is the wrong instrument and we will say so and point you at a dedicated team.
Get a Scope and a Number
Describe what you want built. You will get a written scope, one price and the assumptions behind it — before you commit to anything.