The contract model should match the uncertainty
Fixed price and time and materials are not competing ideologies. They are ways of allocating uncertainty between a buyer and a software team.
The mistake is choosing a model before understanding what is actually uncertain. If everyone agrees on the outcome, workflows, exclusions, and acceptance criteria, a fixed-price scope can create useful budget clarity. If the team is actively learning from users and changing priorities, time and materials can be more honest, provided the buyer has a disciplined way to control the backlog and spend.
The goal is not to make uncertainty disappear. It is to make it visible before it becomes a surprise invoice, delayed launch, or argument about what was promised.
Quick choice: Choose fixed price for a defined first outcome with written acceptance criteria. Choose time and materials only when priorities will change and the buyer can provide a product owner, a budget cap, weekly review, and backlog authority. When uncertainty is high, start with a small fixed discovery phase instead of forcing either model too early.
The core difference
| Contract model | Buyer commits to | Team commits to | Works best when | Main risk |
|---|---|---|---|---|
| Fixed price | A defined scope and change process | Specific deliverables for an agreed price | The first release and its boundaries are clear | Treating ambiguous requirements as included work |
| Time and materials | Paying for effort within a managed budget | Capacity and transparent progress | Priorities will evolve as the team learns | Spending continues without a firm delivery decision |
Either model can include high-quality engineering, testing, documentation, and ownership. Either can also fail if scope, responsibilities, and decisions are vague.
Time and materials is normally billed for actual effort at agreed rates. Before it begins, agree on an invoice cadence, a not-to-exceed or review cap, who can prioritize the backlog, and when the team must stop for a budget or scope decision. An estimate without these controls is not a budget.
When fixed price is a good fit
Fixed pricing is usually strongest when the buyer can describe a focused result rather than a broad wish list. Examples include a defined internal workflow, a clearly bounded integration, a product MVP with one primary user loop, or a known modernization project.
Before a fixed price is credible, the scope should answer:
- What user or operator completes which workflow?
- Which screens, records, roles, integrations, and outputs are included?
- What is explicitly excluded from the first release?
- What assumptions must remain true for the plan to hold?
- What evidence will show that each milestone works?
- How will a new requirement be evaluated and approved?
If the project needs those answers but nobody has them yet, discovery is not overhead. It is the work required to turn a risky request into a fair fixed-price proposal.
Somnio’s 12-week AI MVP guide shows how a clear product loop, exclusions, access, and acceptance criteria protect a focused delivery target.
When time and materials is a good fit
Time and materials can be the right model for work that is genuinely ongoing or exploratory. It is often appropriate for:
- Staff augmentation where the buyer directs daily priorities.
- A mature product team with a maintained backlog and delivery cadence.
- Maintenance, performance work, or support where incoming work cannot be predicted precisely.
- Research or discovery before a defined build scope exists.
For this model to stay healthy, the buyer needs active participation. Set a budget cap, review work frequently, keep a prioritized backlog, and decide what is considered done. A time-and-materials agreement is not a substitute for product management.
A practical middle path is often: fixed-price discovery or validation, fixed-price build of the first product loop, then time-boxed time and materials only for intentional learning after launch. This lets the buyer price the first irreversible commitment while retaining flexibility for evidence-driven improvements.
Compare proposals by the evidence they contain
Do not compare a fixed bid to an hourly rate without looking underneath both. Use the same questions for every proposal.
| Decision area | Evidence to request |
|---|---|
| Scope | Workflow map, deliverables, assumptions, dependencies, and exclusions |
| Quality | Acceptance criteria, QA approach, demos, and issue-resolution process |
| Timeline | Milestones, decision points, required access, and what can change the schedule |
| Budget | Fixed deliverables or a time-boxed capacity and budget cap |
| Changes | Written process for describing, estimating, approving, and scheduling new work |
| Ownership | Repository, custom-code, account, documentation, and handoff expectations |
| Support | Post-launch support, defect handling, and future-maintenance options |
A proposal that cannot explain these items is not made safer by calling itself agile or fixed-price.
Change control is the real test
The strongest fixed-price proposal does not promise that the buyer will never have another idea. It establishes what happens when they do.
A practical change process has four steps:
- Describe the requested outcome and why it matters.
- Identify the effect on scope, architecture, testing, budget, and timeline.
- Decide whether it replaces a current priority, becomes a separately priced change, or waits for a later phase.
- Record the decision before implementation starts.
That process is also useful under time and materials. It protects the team from quietly filling the backlog with unreviewed requests and helps the buyer see the opportunity cost of every new priority.
Ownership terms belong in the contract conversation
Pricing cannot be separated from ownership. A lower initial rate can become expensive if the client cannot access the repository, hosting accounts, deployment instructions, or the operational knowledge needed to make a change later.
Before signing, ask:
- Who owns custom code after payment, and what does the signed agreement say?
- Where is the code repository, and who has administrator access?
- Who controls production accounts, domains, API credentials, and backups?
- What documentation and deployment instructions are included?
- Can another qualified developer run and extend the application?
- Which third-party licenses or proprietary components remain subject to separate terms?
Somnio’s fixed-price and IP ownership policy explains its published approach and notes that final IP, licensing, and ownership terms belong in the signed agreement.
How Somnio uses fixed scopes
Somnio generally uses fixed-scope delivery when a customer needs a defined outcome and can make the key workflow, integration, and launch decisions before implementation. Public packages include a $2,000 one-week workflow audit, a $5,000 AI opportunity and implementation sprint, and a focused 12-week AI MVP package starting at $20,000 when the requirements fit.
Those starting points are designed to make the scope conversation concrete. They are not a claim that every software problem belongs in a fixed package. Undefined, multi-quarter, staff-augmentation, or continuously changing work may need discovery or a different engagement model first.
Bottom line
Choose fixed price when you can define the outcome and want the scope, budget, and change process made explicit. Choose time and materials when ongoing learning is essential and the buyer can actively control priorities and budget. In both cases, insist on clear ownership, acceptance criteria, communication, and a documented path for change. The best contract is the one that lets both sides make tradeoffs before they become expensive surprises.
