How to scope a software project and estimate its cost

Why most estimates are wrong

Software estimates fail for predictable reasons: the scope was described as features rather than outcomes, integrations were treated as a single line item, data migration was forgotten, and non-functional requirements such as security or availability were assumed rather than stated. The number was not wrong because estimators cannot add; it was wrong because it described a different project from the one that got built.

A scoping template that works

1. Outcome

One or two sentences: what will be measurably better, and for whom? For example: "Field technicians close work orders on their phones the same day, so billing happens within 48 hours instead of two weeks."

2. Users and journeys

Journeys, not screens, are the right unit for estimation. Each journey crosses several screens and back-end services.

3. Integrations and data

For each integration, record the system, the direction of data, the method (API, database or file), who owns it, and whether documentation and test environments exist. Unknown or undocumented integrations are the largest single source of overruns. Data migration deserves its own line: volume, quality, transformation rules and how many trial runs are needed.

4. Non-functional requirements

• Expected users and peak load
• Availability target and support hours
• Security and compliance obligations
• Hosting: cloud, on-premises or hybrid
• Accessibility and languages
• Devices and browsers

5. Constraints

Deadlines, budget ceilings, mandated technologies and internal team availability.

Estimating: parts, ranges and assumptions

1. Size each journey and integration with the engineers who will build it, using best-case and likely-case figures.
2. Add cross-cutting work: design, testing, DevOps, documentation, project management and training. Together these are a significant share of total effort and are often omitted.
3. Express a range and name the assumptions behind it, for example "assumes the ERP exposes order data through a documented REST API".
4. List exclusions explicitly.

Discovery: the cheapest risk reduction

For projects longer than about three months, a short discovery phase pays for itself. It turns unknowns into knowns: integrations are tested, a prototype validates journeys with users, and the architecture is agreed. The estimate that follows is narrower and more trustworthy, and it is useful to you even if you choose another vendor.

Define a real first release

A first release should let at least one user group complete its core journeys end to end in production. Everything else can follow in planned phases. This keeps budgets controlled and puts working software in front of users early, where feedback is cheapest to act on.

A checklist before you request quotes

• Outcome written in one or two sentences
• User roles and top journeys listed
• Integrations named with owners and access method
• Data migration volume and sources known
• Non-functional requirements stated
• Budget range and deadline shared honestly

Our custom software development engagements start with this method. If you are still deciding whether to build at all, read custom software vs off-the-shelf, or send us a brief through start a project.