How to scope a software project before you hire anyone

Most software projects that go badly were in trouble before anyone wrote a line of code. The vendor was hired on a vague description, the estimate was a guess presented as a number, and the first month went to discovering what the project actually was. You can avoid most of that with a few days of structured thinking before you contact a single agency or freelancer.

This is the process we would follow if we were on your side of the table. It doesn't require technical knowledge. It produces a short document, usually four to six pages, that any competent team can estimate against and that you can use to compare their answers.

Start with the problem, not the feature list

The most common scoping mistake is opening with a list of features: login, dashboard, notifications, admin panel. Features are solutions. Before you commit to them, write down the problem in plain language: who is affected, what they do today, and what it costs you when it goes wrong.

A useful test is whether someone outside your company could read the problem statement and explain back why it matters. "Our field technicians fill in paper forms that office staff retype the next day, which delays invoices and introduces billing errors" is a problem. "We need a mobile app" is not.

• Who the users are, by role, and roughly how many of each.
• What they do today, step by step, including the spreadsheets, emails and workarounds.
• Where the current process breaks: delays, errors, lost revenue, compliance exposure.
• What a good outcome looks like in six months, described as a change in behavior or cost rather than as a screen.

Describe the core workflows end to end

Once the problem is clear, pick the two or three workflows that matter most and walk through them from the user's point of view. Write them as short numbered steps. A technician opens a job, records the parts used, captures the customer's signature and submits. The office sees the job appear, checks it and sends an invoice.

Workflows expose the questions that feature lists hide. Does the technician need to work without a signal? Who can edit a job after it is submitted? What happens when the customer disputes the invoice? Each answer changes the estimate, and it is much cheaper to answer them on paper than in code.

Separate the first release from everything else

Every project has more ideas than budget. Sort them into three groups before you talk to vendors: what must exist for the first release to be useful, what you want soon after, and what is speculative. Be strict with the first group. If the first release can launch without a feature and still solve the core problem, that feature belongs in the second group.

This isn't only about cost. A smaller first release reaches real users sooner, and real usage is the best source of information about what to build next. Many second-group features turn out to be unnecessary once people are using the product, and others turn out to matter more than anyone expected.

List the constraints you already know about

Constraints shape architecture more than features do, and vendors can't guess them. Write down anything that is already decided or non-negotiable.

• Systems you must integrate with: accounting software, a CRM, an ERP, a payment processor, single sign-on.
• Platforms: web only, or iOS and Android too, and which browsers and devices your customers actually use.
• Data rules: where data must be stored, how long it is kept, and whether you handle health, financial or children's data.
• Accessibility and legal requirements, such as WCAG conformance for public-facing products.
• Hard dates tied to something real: a trade show, a contract renewal, a regulatory deadline.
• Who will own the code, the cloud accounts and the domain during and after the engagement.

Decide what you will provide

Software projects slow down most often while waiting on the client: content, brand assets, access to a system, a decision from someone who is busy. Name the person who can make product decisions and how much time they can give each week. A few dependable hours of a decision-maker's time per week is often the difference between a project that moves and one that stalls.

Also list what already exists: designs, a previous version, API documentation, test accounts, brand guidelines. Existing assets can shorten a project, but only if the vendor knows about them up front.

Set a budget range and say it out loud

Many buyers withhold their budget, hoping to get an unbiased estimate. In practice it produces proposals that are impossible to compare: one vendor proposes a lean version, another proposes everything. Sharing a range lets each team tell you what they would build for that money and what they would leave out, which is the comparison you actually want.

If you genuinely don't know what software costs, say so, and ask each vendor to propose two options at different price points with a plain explanation of the difference.

Turn it into a short brief

Put everything into one document. It doesn't need a template; it needs to be readable in fifteen minutes. A structure that works well:

1. Background: the company, the problem and why it matters now.
2. Users and workflows: the roles and the two or three core workflows, including what goes wrong.
3. First release: the must-have list, plus the soon-after list for context.
4. Constraints: integrations, platforms, data rules, dates and ownership.
5. Your side: the decision-maker, their availability and the assets you can provide.
6. Budget and timing: a range and a target date, with the reason for the date.

Use the brief to compare vendors

A good brief changes the conversation. Instead of asking how much an app costs, you can ask how a vendor would approach your hardest workflow, what they think is missing from the brief, and what they would cut to hit your budget. Pay attention to the questions they ask. A team that pushes back on parts of your brief is usually a team that read it carefully.

Ask every vendor the same practical questions: who will actually do the work, how often you will see working software, how changes in scope are handled and priced, and what you receive at the end. You should own your repositories, cloud accounts and domains from the start, not after a final payment.