Scoping worksheet · inputs, ranges, risk factors
Estimate a custom build without guessing — or getting surprised later.
A worksheet that walks you from a fuzzy idea to a defensible cost range: the inputs to gather first, a method for sizing the work, realistic ranges from a decade of builds, and the risk factors that quietly move the number. Use it to pressure-test a vendor quote or to scope your own project before you ask.
Why most software estimates are wrong
Software estimates go wrong for predictable reasons: the requirements were vague, the integrations were unknown, and someone collapsed an honest range into a single confident number to win approval. The result is a project that runs over not because the team was slow, but because the estimate was a guess dressed up as a commitment. The fix is not a better crystal ball — it is a disciplined process that gathers the right inputs, sizes the work honestly, and expresses the answer as a range that narrows as unknowns resolve.
This worksheet is the method we use to scope custom business software builds. It works just as well as a buyer's tool: bring it to a vendor conversation and you will immediately spot a quote that skipped the cross-cutting work or ignored the integration risk. If you are still deciding whether to build at all, start with the build-vs-buy playbook first.
1. Inputs to gather before you estimate
- The problem in one sentence: what the software must let users do, and what it replaces today.
- The primary user roles and how many distinct permission levels exist between them.
- The core feature list for version one, separated from the nice-to-haves you can defer.
- Every external system the product must integrate with, named, with its authentication method noted.
- Whether existing data must be migrated, from what source, and at what volume and cleanliness.
- Security and compliance obligations: regulated data, audit logging, single sign-on, or certification targets.
- Expected scale: concurrent users at launch and the growth curve over the first year.
- Hard constraints: a deadline tied to an event, a fixed budget ceiling, or a required technology.
2. A method for sizing the work
- Break the v1 feature list into discrete capabilities, not vague themes. 'User management' becomes signup, login, roles, invitations, and deactivation.
- Size each capability as small, medium, or large by the engineering effort it carries, including the unglamorous parts: validation, error states, and edge cases.
- Add the cross-cutting work that every build needs but feature lists omit: authentication, authorization, logging, monitoring, and a deployment pipeline.
- Account for the non-coding effort: design, code review, testing, project management, and the post-launch hardening that turns a demo into a system.
- Convert sized capabilities into an effort range, then a cost range — never a single number this early.
- Reality-check the total against comparable builds so a wildly low or high estimate gets caught before it reaches the client.
3. Realistic cost ranges
- MVP or proof of concept: roughly $40K–$120K. A focused first version that proves the core workflow with real authentication and data, not a clickable mock-up.
- Production-grade application: roughly $120K–$400K. Multi-role, integrated, secured, and hardened enough for the business to run on day to day.
- Platform or multi-tenant SaaS: $250K and up. Tenant isolation, billing, admin tooling, and the operational maturity to onboard customers safely.
- Ongoing maintenance: budget 15–22 percent of build cost per year for fixes, dependency updates, security patching, and small enhancements.
- Discovery sprint: a short, fixed-fee phase that produces wireframes, a data model, and a confirmed scope so the build estimate tightens dramatically.
4. Risk factors that move the number
- Unclear or shifting requirements. The single largest source of estimate error; vague scope is expensive scope.
- Third-party integrations you do not control, especially legacy or poorly documented APIs that behave differently than the docs claim.
- Data migration from messy legacy systems, where cleaning and reconciling the data costs more than moving it.
- Compliance and security requirements discovered late, which can ripple through architecture decisions already made.
- A single internal stakeholder who must approve everything but is rarely available, stalling decisions and inflating timelines.
- Optimism bias: the natural tendency to estimate the happy path and forget that real projects spend significant time on edge cases and rework.
How to use the worksheet
Work through the four sections in order in a single sitting. Gather the inputs first — do not start sizing until you can name every integration and every user role, because the gaps you find here are exactly the gaps that blow up later. Then size the v1 feature list capability by capability, add the cross-cutting and non-coding work, and convert the total into a range. Finally, walk the risk list and widen the range for every factor that applies to you.
Estimate the first shippable version in detail and treat later phases as rough ranges. The goal is not a multi-year forecast to the dollar; it is a defensible number for the work in front of you and an honest acknowledgment of what is still unknown. If a custom build is the direction, the MVP to Production Playbook explains what the "production-grade" line item in your estimate actually buys, and the build-vs-buy analysis for 2026 puts the cost ranges in context.
How this connects to our work
Every estimate we produce follows this worksheet, and when the unknowns are too large to estimate responsibly, we recommend a short, fixed-fee discovery sprint that produces wireframes, a data model, and a confirmed integration list. That single step usually moves an estimate from plus-or-minus 50 percent to plus-or-minus 15 percent. We apply the same method across SaaS platform development and API development engagements.
If you want a second opinion on a quote you have already received, or a real estimate for a project you are scoping, see how we price discovery and delivery or send us the inputs from this worksheet and we will turn them into a range.
Frequently asked questions
Why estimate as a range instead of a single number?
Because a single number pretends to a precision that does not exist before discovery. A range communicates honest uncertainty and narrows as scope, integrations, and unknowns get pinned down. A credible early estimate is a range; a credible late estimate is a tighter range.
What are the biggest drivers of a software estimate?
Integration count and complexity, the number of distinct user roles and permissions, compliance and security requirements, data migration from legacy systems, and how clearly the requirements are defined. Vague requirements and unknown third-party systems inflate estimates the most.
Should I estimate the whole product or just the first version?
Estimate the first shippable version in detail and the later phases as rough ranges. Trying to estimate a multi-year roadmap to the dollar is wasted effort; the requirements will change before you get there. Scope a real v1, ship it, and re-estimate from real data.
How accurate can an estimate be before discovery?
Treat a pre-discovery estimate as plus-or-minus 50 percent. After a short paid discovery sprint that produces wireframes, a data model, and a confirmed integration list, you can usually get within plus-or-minus 15 to 20 percent on the first phase.
Related resources & reading
Build vs Buy Decision Playbook
Decide whether to build at all before you estimate the build.
MVP to Production Playbook
What the "production-grade" line in your estimate really covers.
Build vs Buy Software in 2026
Where these cost ranges fit in the broader decision.
Custom Business Software
Our delivery service for when the estimate gets approved.
Want a real estimate, not a guess?
Fill in the inputs section, then book a call. We will turn your worksheet into a defensible range and, where the unknowns are large, propose a discovery sprint that tightens it. See how that is priced first if you like.