The decision
The useful starting point for a software budget is the work people need to complete, including the exceptions. A page count hides the difficult parts: permissions, imported records, external systems, recovery after failure and the evidence needed before release. Two products with five screens can therefore require very different amounts of work.
A worked example
Consider an illustrative supplier portal. Assume 8 days for discovery and design, 15 for the main workflow, 6 for integration, 5 for verification and 3 for release preparation: 37 person-days. These are invented planning assumptions, not a quotation or a market benchmark. Multiplying them by an agreed daily rate produces a labour estimate; hosting and ongoing support remain separate.
Turn an estimate into a scope ledger
Make the estimate inspectable by separating each workstream into a promised outcome, an assumption, an owner and acceptance evidence. For the supplier portal, “integration” is too broad to review. A better entry says that an approved order reaches the supplier once, receives an external reference and remains visible when delivery fails. Next to it, state whether the supplier offers a test account and who provides it. This prevents a low estimate from quietly depending on unpaid work by somebody else. Ask for the same structure from every bidder so apparently different prices can be compared against the same responsibilities.
Price the exceptions as deliberately as the main route
Choose a troublesome order and walk it through the ledger: one item is withdrawn, the delivery address changes after approval, and the supplier replies late. Which work is already inside the estimate? Which assumption is now false? A useful review changes a specific line rather than reopening the whole proposal. Where evidence is missing, agree a small investigation and the decision it will unlock. Do not confuse contingency with permission to expand the product: contingency covers uncertainty within a promise, while a new promise needs a scope decision.
Keep release cost separate from ownership cost
After the first release, somebody must check backups, apply updates, investigate failed transfers and answer operational questions. Decide whether those responsibilities belong to the business, the studio or another provider and describe the handover between them. Ask how a support request becomes authorised development rather than assuming all future changes are included. Before accepting the estimate, verify a sample acceptance test, the named exclusions, external charges, ownership of accounts and the treatment of unused contingency. The purpose is not to predict every future invoice; it is to make later decisions traceable to an agreement both sides can understand.
Alternatives worth weighing
Ask for a range where uncertainty is real. A documented supplier API permits a narrower integration estimate than an undocumented export. A small paid discovery exercise may resolve that uncertainty; a fixed scope can work when acceptance examples and dependencies are already known. Neither pricing model removes the need to define responsibility.
Where the plan breaks
Do not hide data cleanup inside development or treat testing as whatever time remains. Record what the estimate excludes and which customer decisions can change it. Add contingency against named risks, such as missing credentials, rather than an unexplained percentage.
Before you commission the work
Before commissioning, ask who supplies sample data, who approves access rules and what counts as a completed transaction. Bring those answers to a custom software discussion. A useful estimate explains its assumptions and the next evidence that could change them.