A defined build with a fixed price, fixed deliverables, and acceptance criteria agreed up front. Best for well-understood scope with a clear finish line.
Fixed price, moving scope
Fixed-price engineering has a bad reputation for good reasons. Vendors bid low, then treat every clarification as a change order. Or they pad heavily and you overpay for risk that never materializes. The underlying cause is the same in both cases: the scope was never defined precisely enough to be fixed, so it gets renegotiated under pressure once work is underway and trust is the first casualty.
How we run fixed scope
- A short paid discovery to define scope precisely before any price is committed
- Written acceptance criteria per deliverable, so "done" is testable rather than debatable
- A fixed price covering everything in that scope, including the integration work vendors usually exclude
- A named change process with pricing, so genuine additions are handled openly rather than as leverage
- Milestone demos, so problems surface early instead of at final delivery
- Documentation, tests, and handover included in scope rather than sold separately
How we work
Run discovery first, priced separately, and produce the specification and acceptance criteria
Quote the build against that specification, or tell you honestly that it should not be fixed-price
Build to milestones with demos, so scope drift is visible immediately
Verify against acceptance criteria, hand over, and close the engagement
Typical stack
Frequently asked questions
Because a fixed price on an undefined scope is either a low bid you will pay for in change orders, or heavy padding you overpay for. Discovery produces the specification that makes a fixed price honest. It is priced separately and small relative to the build, and you own the output whether or not you proceed with us.
When the requirements will genuinely change as you learn, which is common in AI and product discovery work. Fixing scope there forces you to commit to a plan before you know enough, and you end up paying for the wrong thing precisely. A pod or retainer suits that better, and we will say so rather than sell the fixed-price version.
That is normal and there is a defined process for it: the change is specified, priced, and approved before work shifts. What we avoid is silent scope creep, which is what makes fixed-price engagements end badly for both sides.
The written acceptance criteria, agreed during discovery, in testable terms. Not a demo that looked convincing and not a subjective judgment on either side.
Go deeper
Define a fixed-scope build
Describe what you need built and we will propose discovery, then a fixed price against the specification it produces.
Start a project