· 5 min read
Fixed price or hourly: how to buy custom software without surprises
How fixed-price and hourly software projects differ, what a good written proposal should contain, and the questions that protect your budget before any work begins.
Two ways to pay for software
With hourly or daily billing you pay for time spent. It is flexible, but the final cost is only known at the end, and the risk of the work taking longer sits with you.
With a fixed price you agree the scope, timeline and cost in writing before work starts. The team takes on the risk of estimating well, and you know your budget from day one. The trade-off is that changes to the scope are agreed and priced separately.
What a good proposal should include
Whichever model you choose, insist on a written proposal. It should answer these questions plainly:
- What exactly will be built, and what is not included
- The timeline, broken into stages you can see and test
- The total price, and how and when it is paid
- How changes you ask for later are handled and priced
- Who owns the code, data and accounts at the end
- What support looks like after launch
How to keep a project on budget
Most overruns come from unclear requirements, not slow developers. Spend time on the first conversation: explain how your business runs today, what is slowing you down, and what a good result looks like. A team that asks a lot of questions at this stage is usually protecting your budget.
Start with the smallest version that solves the main problem. A booking page or a stock system that works well is worth more than a large system that is still unfinished. Further parts can be added once the first one is in use.
Red flags to watch for
- A price given before anyone has asked how your business works
- No written scope, or a scope too vague to check against
- No working software to see until the very end
- Reluctance to hand over the source code and accounts