How to Scope a Software Idea Before You Hire Anyone to Build It

Software ideas often arrive as a sentence: "an app that connects tradies with customers" or "a portal for our clients". Hiring someone to build a sentence leads to blown budgets, missed expectations and features nobody uses. A short scoping exercise before you talk to any developer saves more money than anything else you can do. You end with a one-page brief, a list of things deliberately left out and a clear view of whether to build at all.

Step 1: Write the problem, not the solution

Start with who has the problem and what it costs them. Complete this sentence:

[Type of person] struggles to [do a task] because [reason], which leads to [cost or consequence].

For example, for a hypothetical physiotherapy clinic: "Our patients struggle to reschedule appointments because they must phone during business hours, which leads to missed sessions and empty slots."

Notice that the sentence does not say "app". The solution might be an app, a text message, a form on your website or a setting in your booking software. Keep it open until you have checked.

Step 2: Check whether something already exists

Search before you commit. Look for existing software, a plug-in for a system you already use or a no-code tool such as Airtable (Wikipedia has the background), a form builder or a booking platform. Ask your industry peers what they use.

Score what you find against your problem. If an existing product covers most of the need, configuring it is nearly always cheaper and faster. Custom software earns its cost when:

• Your process is what sets you apart and off-the-shelf tools force you to change it.
• You need to connect several systems in a way no product supports.
• You plan to sell the software to others as a product.
• Per-user fees on existing products add up to more than building would.

Be honest in this step. Sometimes the right advice is "do not build anything". The comparison of custom software vs off-the-shelf goes deeper.

Step 3: Name the users

List every kind of person who will touch the software and what each needs to do. Keep the list short.

User	What they need to do	How often
Patient	Reschedule or cancel an appointment	Occasionally
Receptionist	See changes and fill gaps	Daily
Practice manager	See reports on missed sessions	Weekly

Talk to at least three real users before you go further. Ask them to describe how they do the task today. You will hear things you did not know, and some will change the plan.

Step 4: Describe the core journey

Write the main path through the software as a short story, from first step to finished outcome. For the physio example: "Patient receives a reminder text, taps the link, sees available times, picks one, gets a confirmation. The receptionist sees the change on the day sheet."

If the story needs more than eight or nine steps, the first version is too large. Cut it back to one journey that delivers the main value. If the journey is really a business process, map it first.

Step 5: Separate must-haves from nice-to-haves

List every feature you can think of, then sort them into three groups using the MoSCoW method:

• Must have: the product fails without it.
• Should have: valuable, but a first version can launch without it.
• Not now: everything else.

Be strict. A common mistake is a first version with fifteen features, none of them excellent. Aim for three to five must-haves. Write the "not now" list explicitly, because a written exclusion prevents scope creep later and gives you a roadmap for version two.

Step 6: List the systems it must connect to

Software rarely lives alone. Write down every system it needs to read from or write to: your accounting package (Xero or MYOB), your CRM, your calendar, payment providers, email or SMS, existing databases. Connection work is a common source of surprise cost, so name each one and say what information moves between them.

If you are not sure what is possible, mark it as a question for the developer. Do not assume. Many accounting and CRM products expose an API, and a developer can tell you whether yours does.

Step 7: Note the constraints

Capture anything that limits the build:

• Privacy and data: what personal information the software stores, and where. Obligations under the Privacy Act 1988 and industry rules can apply, so get advice for sensitive data.
• Security and access: who can see what.
• Devices: phone, tablet, desktop, offline use.
• Budget range and decision date. Be honest about both, as they shape the right approach.
• Existing branding and tone.

Step 8: Define how you will judge success

Choose one to three measures you can check after launch. For the physio example: the share of reschedules done without a phone call, and the number of empty slots per week. Take a baseline now, as described in our guide to measuring whether an AI change is working. The same method applies to any change.

Step 9: Plan a small first version

Describe the smallest release that proves the idea with real users. It might be a single screen, a handful of testers or a working prototype. The goal is to learn whether people use it, not to impress anyone.

Ask a developer or agency to price this first version separately from the full vision. Keeping the first commitment small reduces the cost of being wrong. If the first version teaches you something unexpected, you have lost little.

Step 10: Write the brief and ask for quotes

Put everything on one or two pages and send the same document to every supplier. Include the problem, users, core journey, must-haves, exclusions, connections, constraints, success measures and your timeline and budget range.

When quotes arrive, compare them on more than price. Ask each supplier:

• What assumptions did you make?
• What is not included?
• How do changes get handled and priced?
• Who owns the code and the data when it is finished? (See who owns software an agency builds.)
• What happens after launch: fixes, hosting, updates?

Copyable brief template

SOFTWARE BRIEF: [Working name]     Date: ____    Contact: ____

1. PROBLEM
   [Who] struggles to [task] because [reason], leading to [cost].

2. ALTERNATIVES CHECKED
   [Existing tools tried or considered and why they fall short]

3. USERS
   [Role - what they need to do - how often]

4. CORE JOURNEY
   [Step by step story, eight steps or fewer]

5. MUST-HAVE FEATURES (3 to 5)
   1. ____  2. ____  3. ____

6. NOT NOW
   ____  ____  ____

7. CONNECTIONS
   [System - what moves in or out]

8. CONSTRAINTS
   Data and privacy: ____  Devices: ____  Budget range: ____  Decision date: ____

9. SUCCESS MEASURES
   Baseline: ____  Target: ____

10. FIRST VERSION
    [Smallest release that proves the idea]

What to do next

If you have a brief and want an honest view on whether to build, buy or configure, product idea from 21Labs takes an idea from sentence to scoped plan. If you want to see how we approach app work in Sydney, read about app development or custom software. Both start with a free discovery. Send the form below and we reply within 24 hours.