Service
Fixed-price software projects with the scope in writing
You get a written scope, a firm price and a delivery plan before we write a line of code. Then working software arrives every week until launch.
A fixed price only means something if the scope underneath it is real. Most overruns do not come from slow developers. They come from a brief that said “customer portal” and meant forty different things. We spend the first days of an engagement turning your goal into a document: the screens, the rules, the integrations, what is explicitly out, and what we assumed because nobody had the answer yet.
Once you approve that scope, the price is the price. If something new appears, we write it up as a change with its own cost and date effect, and you decide whether it goes in now, later or never. There is no quiet erosion that turns into a surprise invoice, and no pressure on us to cut corners to protect a number.
Fixed price suits projects with a definable finish line: a client portal, an internal tool, a mobile companion, a migration. It is the wrong contract for exploratory work where you will learn your way to the requirements, and we will tell you that on the first call instead of selling you the contract either way.
The problems
What usually goes wrong
Budgets that drift mid-build
Time-and-materials quotes start as a range and end as a different number. You are asked to approve more money halfway through with no way to judge whether the extra work is reasonable.
A brief everyone reads differently
You picture one product, the vendor builds another, and the gap surfaces at the end. Ambiguity is cheap to settle on paper and expensive to settle in code.
Silence until a big reveal
Months pass with status emails and no product to click. By the time you see it, changing direction means rework you are now paying for.
A fuzzy finish line
The code is on the vendor's hosting, the credentials sit in their password manager and the documentation was always going to come later. “Done” has no checklist.
What you get
Deliverables
Written scope document
Screens, user roles, business rules, integrations, assumptions and explicit non-goals, in plain language your whole team can review.
Firm price and milestones
A single price tied to milestones, so you always know what has been delivered against what has been paid.
Weekly working demos
A live walkthrough of the real build every week. You click it, you comment, and the feedback lands in the next cycle.
Change log for every deviation
New ideas become short written changes with their effect on price and date. Nothing moves on a handshake.
Production deployment
The product running in the environment you chose, with monitoring basics and a rollback path.
Handover package
Repository, environment templates, access map, runbook and a short stabilization window after launch for issues we should have caught.
How it works
Step by step
01
Discovery call
We ask who uses the product, which systems it touches, what hurts today and what date matters. If fixed price is the wrong shape, we say so here.
02
Written scope in three days
We return a scope with milestones, assumptions and a price. You can challenge it, trim it or take it to another vendor.
03
Approval and kickoff
Scope and price are locked together. We agree on a shared channel, a demo day and the person on your side who can make decisions.
04
Build with weekly demos
Each week ends with working software. Blockers and questions are raised early and recorded against the scope.
05
Launch and handover
We cut over, train the people who need it and transfer the code and credentials. A stabilization window covers defects against the agreed scope.
Timeline
How long it typically takes
The scope itself is typically back within three days of the discovery call. Small single-purpose builds often take four to eight weeks after approval, while products with several roles and integrations more commonly run two to four months. Third-party approvals and how quickly your team answers questions move those ranges, so the dates in the written scope are the ones we plan against.
Who it's for
- Teams with a clear deliverable and a real deadline or budget ceiling
- Buyers who need a document they can take to finance or another vendor
- Operators who want to approve once and then watch progress, not manage it daily
Who it's not for
- Exploratory products where the requirements will change every week
- Projects that need to start building before anyone has agreed what “done” means
- Teams that want open-ended capacity rather than a defined outcome
Keep exploring
Related pages
FAQ
Frequently asked questions
What happens if the scope turns out to be wrong?
If we missed something that was knowable at the time, that is on us and we absorb it. If the world changed or a new requirement appeared, we write a change with its price and date effect and you decide whether to proceed.
Can we change our minds during the build?
Yes. Swapping a feature for another of similar size is usually straightforward. Adding net-new work is handled as a written change so the price and the schedule stay honest.
How do payments work?
Invoices follow the milestones in the scope, so each payment lines up with something you have already seen running. The exact schedule and payment methods are confirmed in the proposal.
Who owns the code at the end?
You do. Source code, documentation and credentials transfer at handover, and the product does not depend on anything we host for you.
Is fixed price available for ongoing work?
Not really. Ongoing work with a moving backlog fits a product retainer or a dedicated developer better. Many clients start with a fixed-price build and move to a retainer after launch.
Next step
Tell us what you want to build
A short call, then a written scope in plain language before any build starts.
- Fixed scope
- Weekly demos
- You own the code