When you hire a team to build software, one of the first things you'll be asked is how you want to pay. A fixed price, an hourly rate, or something in between. Founders usually lean toward fixed because it feels safe: you know the number up front. But the safe-looking option can be the riskier one, depending on your project.
Fixed price
You agree on a defined scope and a total price. The team delivers that scope for that amount.
It works well when the requirements are clear and unlikely to change. Think of a standard company website, a small tool with a well-understood job, or a defined integration. You know what you're getting, and you know what it will cost. Budgeting is easy.
The catch is that software requirements rarely stay still. Once you see the first version, you'll want changes, and every change is a negotiation. Teams protect themselves by padding the quote, writing the scope narrowly, and charging for anything outside it. When money is tight and the specification is vague, that's where arguments start.
There's also a quieter risk. With a fixed price, the team makes more profit the faster and cheaper they finish. Most people act professionally, but the incentive is there, and corners can be cut where you can't easily see them, such as testing and code quality.
Hourly, or time and materials
You pay for the hours spent, usually at an agreed rate, often with a monthly cap or review.
It works well when you're not sure exactly what you need. Early products, experiments and projects that will evolve as you learn all fit. You can change direction without renegotiating, and you only pay for work done. You also get more flexibility to drop a feature that turns out to be a bad idea.
The risk is the opposite one: the final cost isn't fixed, and it can drift. You need to trust the team, and you need visibility, such as regular demos, clear weekly reports and a say in priorities. Without them, hours can pile up with little to show.
Retainer or dedicated team
You pay a regular monthly amount for a team, or a set number of developers, who work on your product continuously.
This suits a product that's live and growing, with a steady stream of improvements. The team learns your business, so you don't re-explain everything for each task. It's usually the best model for the long term, but it only makes sense when there's enough work to keep people busy.
A hybrid that often works
Many good projects use a mix. A short, fixed-price discovery phase to define the scope and produce a proper estimate. Then fixed price for clear chunks, hourly for the uncertain parts. After launch, a small monthly retainer for maintenance.
This protects you where the picture is clear and gives you flexibility where it isn't.
Questions to ask yourself
- How sure am I about what I need? Very sure points to fixed. Unsure points to hourly or phased.
- How likely is it to change? If a lot, avoid rigid fixed scope.
- Do I have time to oversee it? Hourly needs your attention.
- Is my budget a hard limit? If so, cap hourly work, or fix a smaller scope.
- How long will we work together? Longer relationships suit retainers.
Protect yourself, whatever you choose
Insist on regular working demos, such as every one or two weeks, so you see real progress and not slide decks. Make sure you own the code and all the accounts from day one. Agree how changes are handled in writing. And pay in stages tied to things you've actually seen working, not a large amount up front.
The contract type matters less than the relationship. A team you trust and talk to openly will deliver well under any model, and a team you don't will disappoint you under all of them.
