Product delivery
How to scope a custom software project without overspending
Before you ask for quotes, answer these questions. A clear scope is the single biggest lever on cost, timeline and quality.
Ask five agencies to quote "an app like Uber, but for our industry" and you will get five numbers that differ by a factor of ten. That is not because four of them are wrong. It is because nobody knows what is being built yet. Scope is the single biggest lever you have on cost, timeline and quality — and most of it can be defined before you speak to a vendor.
1. Write down the problem, not the features
Start with a short paragraph: who is struggling, with what, and what it costs today. "Our sales team spends two days a week rebuilding the same quote in Excel" is far more useful than a list of screens. Good partners will turn the problem into features with you; a feature list without a problem invites gold-plating.
2. Name your users and their top tasks
List each type of user — customers, staff, admins, partners — and the two or three things each must be able to do. This list usually reveals that the first release needs far less than expected.
| User | Must be able to… |
|---|---|
| Customer | Browse, book, pay, get reminders |
| Staff | See today's bookings, update status |
| Admin | Manage pricing, export reports |
3. Decide what "version one" is
Separate the work into three buckets:
- Launch: without it, nobody can use the product.
- Soon after: valuable, but users can live without it for a few weeks.
- Someday: good ideas to revisit once real usage data exists.
Shipping the launch bucket first gets real feedback sooner and protects your budget from features nobody ends up using.
4. List every integration
Payment gateways, accounting tools, CRMs, SMS and email providers, maps, existing databases — integrations are where estimates most often go wrong. Note which systems you use today and whether they offer an API.
5. Be explicit about constraints
Share your budget range, deadline and any non-negotiables (data residency, accessibility, specific platforms). A range is not a negotiating weakness; it lets a partner propose the best solution within it rather than guessing.
6. Agree how you will work
Decide who on your side owns decisions, how often you will review progress, and how changes will be handled. Short, regular demos of working software beat long status reports every time.
7. Plan for life after launch
Hosting, monitoring, security updates and small improvements continue after go-live. Budget for them up front, and make sure you will own the code, designs and accounts.
Bringing it together
With the problem, users, version-one scope, integrations and constraints on two pages, you will get quotes you can compare like for like — and a much better product. If you would like help shaping that document, a short discovery session is often the quickest route.