ROBATZ editorial · · 5 min read
A useful estimate explains its assumptions
Two proposals can describe the same application and include very different work. One may cover a prototype; another may include migration, accessibility, monitoring and support. Comparing the totals before comparing those boundaries creates false precision. Ask every supplier to describe what will be working at the end, what remains outside the scope and which inputs the client must provide.
Separate the estimate from the commercial model. A fixed price can be appropriate for a clearly defined deliverable, while an evolving product may need a different arrangement. Neither label removes uncertainty. You need a shared process for accepting work, changing priorities and understanding the budget effect before additional work begins.
Count workflows and decisions, not screens alone
A screen count can be a useful inventory, but it misses much of the implementation effort. A simple-looking approval page may need multiple roles, audit records, notifications, delegated access and exception handling. A visually rich information page might have little application logic. Describe what people can do and what rules govern those actions.
For a hypothetical booking product, distinguish browsing availability from reserving inventory, taking payment, rescheduling and issuing refunds. Specify what happens when two customers act simultaneously or a payment provider is unavailable. These details help a team estimate the real workflow and identify a smaller first release without hiding unfinished behavior behind a polished interface.
Investigate integrations and data early
External systems introduce dependencies that a development team does not fully control. Ask whether documentation, test accounts, permissions and sample data are available. A documented API and a manually maintained spreadsheet imply different work. Include error handling, retries, reconciliation and ownership when information disagrees between systems.
Data migration also deserves its own line in the estimate. Determine which records move, what quality problems exist and who decides how conflicts are resolved. A short investigation can test the most uncertain connection before the broader build is committed. Its output should reduce a named uncertainty, rather than produce an impressive prototype unrelated to the delivery risk.
Define quality and operations as part of scope
Specify the conditions the product must handle: expected usage, response time, supported devices, accessibility needs, permission boundaries and recovery expectations. These requirements influence architecture, testing and release work. They should be proportional to the business need and visible in the proposal, rather than introduced as surprises shortly before launch.
The operating model matters too. Who watches errors, rotates credentials, updates dependencies and responds when a third-party service changes? What documentation and access does your team receive? Request a release and handoff plan. A product that can be demonstrated is not necessarily ready to be supported by the people who will own it.
Model recurring costs separately
Development is only part of ownership. Hosting, storage, monitoring, email, payments, model APIs and support can continue after launch. Estimate these costs using explicit usage assumptions, then test how they change as adoption grows. For AI features, include repeated attempts and human review alongside model usage. Use current provider prices instead of a generic monthly allowance.
AWS Pricing Calculator is one tool for modeling configured cloud services; its output depends on the information entered and is an estimate, not a complete product budget. AWS's architecture guidance also treats cost optimization as an ongoing operational concern. Give each recurring expense an owner and revisit the model against actual usage after release.
Ask for a phased proposal you can compare
A practical proposal can separate discovery, a first usable release and later expansion. Each phase should state its deliverables, acceptance criteria, dependencies and budget assumptions. Ask what changes if a difficult integration fails or a required stakeholder is unavailable. Request a range where uncertainty remains, together with the work needed to narrow it.
Compare suppliers using the same brief and the same definition of done. Look for a credible explanation of tradeoffs, evidence that the team understands the difficult parts and a clear way to review progress. The goal is not the lowest number on a page. It is an investment decision you can manage as the product becomes better understood.
Apply this to your product
Explore our Custom web development service for scope, deliverables and the decisions to make before starting.