“An application with login, bookings and payments.” It fits on one line. The work might mean a request confirmed manually by email, or a synchronised calendar with refunds, team permissions and recovery from interrupted payments. Before asking why two estimates differ, check whether they estimate the same thing.
This applies to teams building their own products too: an internal estimate can overlook exactly the same tasks. Useful comparison starts with the expected outcome, the included work and the unknowns. A higher total does not prove quality; a lower total does not prove carelessness.
A feature name hides its rules
Consider a fictional room-booking product. Proposal A includes requests that a person approves manually. Proposal B includes live availability, recurring reservations, charging and automatic cancellation. Both might contain a line labelled “bookings”. Only one describes a small operations department disguised as a button.
Make the distinction testable: who can book, what happens when two people choose the last slot, and who resolves a charge without a confirmation? Then separate the first release from work that can wait. This is an illustrative example, not a Zephyrus project or price.
The GAO’s 2020 estimating guide covers scope, a technical baseline, assumptions, risk analysis and updates using actual costs. It provides a method, primarily in a public-programme context; it is not a price list for a Portuguese app. Our practical application is simple: document what the number estimates. GAO cost estimating guide.
Five areas that deserve their own line
Product and interface: necessary research, journeys, content, empty states and error messages. Integrations: external systems, permissions, limits and failed connections. Data: import, cleaning, validation and export. Quality: testing, accessibility and the devices actually covered. Operations: deployment, monitoring, backups and a recovery procedure.
This breakdown is a working suggestion, not a universal standard. Its purpose is to prevent “included” from meaning different things. Importing a clean sample file is different from reconciling years of duplicate records. Inspect representative data and agree who resolves errors before turning migration into a fixed-price line.
Security needs identifiable work too. NIST’s SSDF groups practices around preparation, software protection, secure production and vulnerability response, adapted to risk and resources. Citing it does not certify a supplier. Ask which concrete activities are included and who handles issues after delivery. Secure Software Development Framework.
An unknown needs an experiment, not theatrical confidence
If an integration is essential but nobody has confirmed API access, the estimate rests on an assumption. Write it down: “The provider permits availability checks and booking creation with these permissions.” Define a small experiment covering authentication, a real operation in a test environment and failure handling. Its result should resolve a specific doubt.
GOV.UK’s discovery guidance puts understanding the problem, users and constraints before the decision to build. Research may justify stopping. Its context is British public services; our application to a small product is to test need and limitations before making a large commitment. We are not automatically importing that context’s timetable or team structure. How discovery works.
A range can be more honest than a single figure under uncertainty, but it needs an explanation: what supports the lower bound, what increases effort, and when will the estimate be revised? A margin without assumptions is just another impressive-looking number. No contingency percentage suits every project.
A short brief that makes comparison possible
Complete seven points before requesting or approving an estimate: person and problem; main task; first release and exclusions; platforms and integrations; existing data; acceptance criteria; operations and ownership. Add the intended date and the real reason behind it. A booked campaign and a preferred date create different choices about what to reduce.
For the fictional booking system, one criterion could be: “When two users try to confirm the same room for the same period, only one booking is confirmed; the other person receives an understandable alternative.” Another: “An administrator can export the agreed records in a documented format.” These are demonstrable outcomes. “Works well” does not do that job.
Send everyone the same brief. Ask them to mark each item included, excluded or awaiting clarification. Compare what you receive as well: code, documentation, appropriately owned accounts and maintenance instructions. Do not assume development includes hosting, external services or future updates.
Compare the whole decision
Separate initial investment, recurring expenses and future changes. State expected usage and who pays for each operating service. A product may be cheap to build while requiring manual work every day; another may automate more than current demand justifies. The initial price alone cannot settle either case.
Before deciding, ask for an explanation of the largest difference between proposals. It may come from scope, reused components, availability, risk or commercial strategy. Without that conversation, choosing the most expensive for reassurance is as fragile as automatically choosing the cheapest.
A good estimate makes decisions visible: what gets solved now, what stays out, which assumption needs testing and how completed delivery will be recognised. It need not predict the future. It should let the next discovery update the plan without turning a technical surprise into an argument about what “obvious” meant.