In this article
Every software engagement starts with a choice about how the work will be bought. A fixed price for a defined scope, a dedicated team billed by the month, or something in between. Each model suits different projects, and choosing the wrong one causes most of the friction that clients blame on the development company later. We offer all of them, so this is a description of when each one works, rather than a sales argument for one.
Fixed price
You agree a scope, a timeline and a price. The development company carries the risk of estimating wrongly, and in exchange the scope is fixed. Changes go through a change request with a cost attached.
This model works when the scope is well understood and unlikely to change: a defined set of screens, a migration with known inputs, a product that replicates an existing process. It gives finance a known number and gives the project a clear finish line. It works badly when the product is still being discovered, because every discovery becomes a negotiation, and because a fixed price gives the development company an incentive to interpret ambiguity in the cheapest way.
Our rule is that a fixed price requires discovery first. One to two weeks of workshops, prototypes and a written specification produce a scope precise enough to price with confidence. We charge for that discovery separately, and the output is yours whether or not you continue with us.
Dedicated team
You engage a team of a defined size for a period, typically with a monthly fee. The team works from your backlog in the order you set, and scope changes as the product does. You see what was delivered each sprint, and you can scale the team up or down with notice.
This model works for products that will keep evolving, for long-term partnerships, and for situations where the client has strong product ownership and wants engineering capacity rather than a project. Most of the mobile and AI products in our case studies run this way after their first release, and several ran this way from the start. It works badly when the client lacks the time to own the backlog, because a team without direction produces work without value, and when the budget is capped and the scope is open, which is a combination that no model handles well.
Time and materials with a cap
Between the two sits hourly or daily billing with a not-to-exceed figure. The team works from a backlog, bills for what it does, and stops or re-plans when the cap approaches. This suits projects with a defined goal but uncertain detail, such as modernising a legacy application where the audit can only estimate so much. It needs transparent reporting to work, so that the client sees progress against the cap in every sprint.
Staged engagements
Many of our projects combine models. A fixed-price discovery produces a specification. A fixed-price first release builds it. A dedicated team takes over for the releases that follow, when the product is live and the backlog is driven by users. This sequence gives finance a known number for the risky part, gives the product the flexibility it needs once it exists, and moves the engagement to the model that fits each stage.
Questions that decide it
- How confident are you in the scope? If a stranger could build it from the document you have, fixed price is possible. If not, discovery first.
- Will the product keep changing after launch? If yes, plan for a dedicated team at some point.
- Who will own the backlog? A dedicated team needs a product owner on your side with real time to give it.
- How is the budget structured? Capital budgets prefer fixed prices; operating budgets suit monthly teams.
- How much do you want to be involved? Fixed price can run with weekly check-ins. A dedicated team works best with daily contact.
What stays the same in every model
Regardless of how the work is bought, you own the code and the accounts from the first day, QA is a dedicated role rather than something developers do when they have time, and every two weeks there is a deployed version you can use. The commercial model changes how risk is shared. It should not change what you receive.
Our engagement models page sets out the options in detail, and the dedicated development centre page covers long-term teams. If you are not sure which fits, describe the project and we will suggest one with reasons.