A fixed price sounds like the safest way to buy software. You know the number up front, and the risk sits with the people building it. But a fixed price is only as good as the scope behind it. A vague proposal with a fixed number usually ends in arguments about what was "included".
Whether you work with us or someone else, these are the sections we think every fixed-price proposal should have.
1. A plain-language summary of the goal
Before any feature list, the proposal should say what problem the software solves and for whom. If you can't recognise your business in the first paragraph, the rest is built on guesswork.
2. A scope written as features and user flows
"Admin dashboard" means something different to everyone. A good scope breaks the product into concrete flows:
- Who the users are (for example customers, staff and admins).
- What each type of user can do, step by step.
- Which screens are included.
- Which integrations are included (payments, email, CRM and so on).
3. What's explicitly not included
This is the most underrated section. Listing exclusions, such as "content writing", "native iOS app" or "data migration from the old system", prevents most disputes before they start.
4. Milestones you can actually check
Large projects should be split into milestones that each produce something you can use or click through. Payments tied to milestones keep both sides aligned: you pay as working software arrives.
5. Acceptance criteria
How will you both agree a milestone is done? Simple, testable statements work best: "A customer can reset their password by email" is better than "authentication complete".
6. How changes are handled
Requirements always evolve once people see real software. A good proposal explains what happens then: small changes absorbed within reason, bigger ones estimated separately and agreed in writing before work starts.
7. Timeline and dependencies
A timeline should note what it depends on from your side, such as feedback within a few days, access to existing systems and content delivered on time. Delays on either side should be visible early.
8. Ownership, hosting and handover
Check that you'll own the code and designs once paid, that accounts (hosting, domains, third-party services) are in your name, and that you'll receive documentation. You should never be locked in.
9. What happens after launch
Is there a period for fixing issues? Is ongoing support offered, and on what terms? Launch is the start of real usage, so it shouldn't be the end of the relationship by default.
The bottom line
A fixed price works when both sides share the same picture of the finished product. The more concrete the proposal, the fewer surprises later.
At HalfClicks every project starts with a free discovery call and a written scope like this. If you'd like one for your idea, start a project.
- #Process
- #Pricing
- #Planning