Working with a development team
Fixed-price vs hourly development: what are you buying?
Compare fixed-price and hourly software development by scope certainty, acceptance criteria, change control and ownership before choosing an engagement.
The decision starts with uncertainty
Fixed-price and hourly development assign uncertainty differently. A fixed price works best when both sides can describe the deliverable and how it will be accepted. Hourly work can be useful when investigation or frequent change makes that definition premature.
Neither model makes a vague brief predictable. Before comparing prices, separate the work you understand from the questions that still need investigation.
Compare the trade-offs
Use the model that matches the work, then make the review and approval process explicit.
| Question | Fixed scope and price | Hourly or time-based work |
|---|---|---|
| What is agreed? | Deliverables, acceptance criteria, assumptions and exclusions | Rates, responsibilities, reporting and spending controls |
| What if priorities change? | Assess the impact and approve a scope change | Reprioritize work while monitoring time and budget |
| What should be visible? | Completed milestones and acceptance evidence | Time spent, outcomes and remaining uncertainty |
| Typical fit | A defined release or bounded implementation | Investigation, evolving backlog or ongoing support |
Make a fixed-price scope testable
‘Build a dashboard’ leaves too many decisions open. A better scope names the user roles, data source, views, filters and the actions each role can take. It also describes empty states, permission failures and the expected behavior when an integration is unavailable.
For a client portal, acceptance could mean that a client can submit a request, see only their own records and receive the agreed update when the team changes its status. New billing or reporting features would be separate scope decisions.
Agree how changes work
A change process should make decisions visible without blocking useful feedback. Record the request, explain its effect on delivery and price, and agree whether to add it now, exchange it for another item or move it to the next phase.
For uncertain work, a bounded discovery phase can produce the information needed for a later fixed-price release. The output should be useful: requirements, unresolved risks, a prototype or technical findings, and a recommendation for the next step.
Check ownership under either model
The billing model does not answer who owns the source, controls deployment accounts or maintains the product. Put those responsibilities in the agreement, along with third-party licenses, documentation and the handover process.
At Aevlorn, the agreed scope has a fixed price before development begins. Working demos every two weeks make progress reviewable. Additional features are assessed and priced for approval, and the project code and setup documentation are part of the handover.
Five questions before you commit
A useful proposal should answer these clearly enough that both sides can tell when the agreed work is done.
- What exactly will be delivered, and what is excluded?
- Who supplies designs, data, access and feedback?
- How will we test and accept the release?
- How are scope changes and additional costs approved?
- What source access, documentation and support remain after launch?
Put the plan into practice
A useful first conversation
Let’s define what to build first.
Bring the problem, your users and the constraints. We’ll discuss the next step and what needs to be scoped.