A fixed price sounds simple: one number, one job, no surprises. In practice the surprises do not disappear. They move into the argument about what the number was supposed to cover. A good estimate for a small software job, such as an order form, a reporting page or a small internal tool, is less about the number and more about the page of text around it.
This article is for an owner or manager who is asking for a fixed price, or a small team that has to give one. It shows what to put into the number and what to leave out on purpose. For the choice between fixed price and time and materials, see Fixed price or time and materials.
Start with the scope
Write the scope as results that a person can check. "Staff can enter an order, see its status and export the week's orders to a spreadsheet" is a scope. "Order management module" is a label.
A short scope usually covers:
- Who uses it and on what device
- The three to six things they must be able to do
- What data goes in and out, including any file or system it connects to
- What "finished" looks like: how you will both test it before saying yes
If you cannot describe the result in a page, the job is not yet small enough for a fixed price. Split it, or do a short paid discovery first.
Write the assumptions down
Every estimate rests on things the supplier believes are true. Put them on paper, because each one is a condition under which the price holds. Typical examples:
- You provide the content, logos and sample data by an agreed date.
- One person on your side answers questions within two working days and approves each stage.
- The system you connect to has a documented interface that works as described.
- The tool runs on the hosting you already have, or on a named service.
- Feedback arrives in one round per stage, not as a stream of small changes.
When an assumption turns out to be wrong, the conversation is about that line, not about who is to blame. That is the whole point of writing it.
Add a buffer and name it
Software has unknowns, and an estimate with no room for them is either optimistic or quietly padded. Show the buffer openly. A common starting point for a small job is 10 to 20 percent, higher where a connection to an unfamiliar system is involved. These figures are a rule of thumb, not a standard; adjust them to how much is unknown.
Then agree what happens to it. Some pairs agree the buffer is part of the fixed price and the supplier keeps what is not used. Others agree it is spent only with the client's approval and unused money is not charged. Either works if it is written down before work starts.
Say what is out of scope
The most useful part of an estimate is often the list of things that are not in it. Name the ones people tend to assume:
- extra user roles, languages or devices
- data migration from old files or systems
- training, documentation beyond a short handover note
- hosting, domain and third-party licence costs
- changes after approval of a stage
- support after delivery, unless a period is stated
Anything on this list can still be done. It is simply priced separately, as a change, with its own short note of cost and time.
Handle changes in one line
Agree one rule for change requests: the supplier writes the effect on price and date, the client approves it in writing, and only then does the work start. A short email is enough. Without this rule, a fixed price slowly turns into an unmeasured time and materials job.
Pay in stages you can see
Tie each payment to something you can open and check, not to elapsed time. For a small job, three parts are common:
- Start: a deposit once scope and assumptions are signed.
- Working version: a payment when you can try the main scenario with test data.
- Handover: the last payment after your acceptance test passes and the files and access are delivered.
Keep the last part large enough that finishing matters to both sides. If the job is very small, two parts are enough.
A one-page checklist
Before you sign or send an estimate, check that the page contains:
- the scope as checkable results
- the assumptions, each in one sentence
- the price, the buffer and the rule for it
- the out-of-scope list
- the change rule
- the payment stages and the acceptance test
If any item is missing, the number is not finished yet. For a wider structure around price and timeline, see Writing a one-page proposal for a small client.
Sources
- Practical guidance based on common software project practice, offered as a planning aid. The buffer range, payment stages and sample assumptions are starting points to adapt to your own job and contract. No client results or product performance figures are claimed in this article.