How to scope business software before writing the first line of code

The question that arrives first is often the stack. Next.js, .NET, a relational database, a low-code tool. It is early. Until you know who uses the system, what they are trying to complete, and what happens when the usual case does not hold, the technology has nothing solid to decide.

Scoping is how you get there. Not a document nobody will reread. A shared picture precise enough that the first increment is useful, and that the architecture follows from real constraints.

Start from the real process

The written procedure and the work diverge. The manual says a request is approved in the tool. In practice the approval leaves by email, a spreadsheet tracks the exceptions, and one person “knows” which files can move without the missing document.

Talking to users is not enough if they describe the ideal process. Watch one operation through to the end: an order, a case, a field job, a close. Who opens it, who completes it, who blocks it, who chases it, and where the information is copied.

The useful gaps are concrete. A required field everyone bypasses. A status that matches no decision. A list exported every morning because the screen cannot filter. Those workarounds are the specification the current system failed to carry.

Define the problem before the solution

Requests often arrive already translated into features. “We need a portal”, “a workflow”, “a mobile app”. Accept that translation too quickly and you build the screen that was named, not the problem that was had.

A problem is easier to scope as decisions and outcomes. What information is missing when someone has to say yes or no? What is retyped, and how late? Which mistake is expensive, and how often? What must still be possible if the new tool is down?

That wording changes the scope. You can ship case tracking without document upload, or the reverse, depending on which one removes more friction. A feature list does not give you that order.

Map what already exists

The new software does not arrive in an empty room. There are applications, files, mailboxes, APIs, nightly exports, sometimes a direct database access that “nobody touches”.

The useful map is not an enterprise architecture poster. It is the list of things that hold a piece of data the new system will need, or might overwrite:

• the application that is the reference today, even if it is old;
• the spreadsheets that correct it;
• the messages that carry a decision;
• the APIs or files exchanged with a partner, an ERP, another business tool;
• the time dependencies: close, billing, on-call, sync.

For each one, three questions are enough. Who owns it? What happens if it is wrong? Can you do without it during a transition?

This map avoids two symmetrical mistakes. Reconnecting everything “later”, then discovering in testing that a status comes from a system you did not plan for. Or integrating everything on day one, and never shipping the path that justified the project. When the gain is mostly to move information that is already captured elsewhere, connecting systems is often a better frame than a whole new product.

Name the users and their decisions

“The users” is too wide. A clerk, a field operator, an external client and a manager reading a board do not share the same moment, the same information, or the same tolerance for a mistake.

For each role, one sentence helps: at moment X, this person decides Y, with information Z, and the consequence is W. If the sentence does not hold, the role is vague or the decision is not real.

Access rights fall out of those sentences, not out of an org chart. Who can correct data that has already been sent on? Who can see a case that is not theirs? Who must be stopped from approving what they entered themselves? Those questions shape the model more than the framework does.

Field conditions belong in the same pass. Intermittent network, gloves, sun on the screen, one free hand, a few seconds of patience. If the software lives outside an office, those constraints are part of the scope.

Make the business rules explicit

The normal case

The normal case is the path people can narrate. A complete request, stock available, a known customer, an approval inside the delay. Describe it through to what is stored and who is notified. It is not the system.

The exceptions

Exceptions are the software. A partial credit. An unreadable document. A third party that does not exist in the reference data yet. A local rule only one team applies. A case that must leave the flow and come back later without losing its history.

Each exception gets the same treatment. What is the condition? Who decides? What trace remains? Can the case continue, or must it stop? If nobody can answer, that is not a detail for development. It is a hole in the rule, and the code will not fill it cleanly.

Set a first useful scope

A first scope is not a product cut at random to fit a budget. It is a complete path for a real case, used by real people, with a way to tell whether it helped.

The test does not need a sophisticated metric. Less retyping on that kind of case. An observable handling delay. One named spreadsheet gone. What matters is that the team can see the effect and choose the next step from that, rather than from the original plan.

Everything outside the path stays visible: you write it down, you do not build it. “While we are here” features are the usual way to miss a scope that was otherwise clear.

This often sits next to automating a business process, when the gain is the removal of manual copies, or modernising software already in place, when the point is to replace part of an existing system without switching it off.

Choose the architecture after that

Constraints come before technology. Volume, peaks, personal data, response time, offline use, systems you must not break, the team that will take the code over, a two-year horizon or a ten-year one. Two contexts that “want a web app” do not want the same architecture.

You can then pick a technical frame without dressing up a preference. A modular monolith or separate services, depending on how many teams ship and how often. A relational database when rules and history matter. Files and queues when the business is an exchange, not a form. Authentication taken from the directory you already have, rather than a second account to manage.

Building comes after that choice, not instead of it. Writing the software without this step means coding assumptions. Assumptions can be corrected. They are cheaper written in a scope than scattered through the code.

What a good scoping effort should produce

At the end, the people who decide and the people who will build should be able to reread the same material and recognise the real work. The output is a short set of pieces, not a binder:

• a shared picture of the process, including the workarounds;
• the problem stated as decisions, not screens;
• a map of what exists and which data is the reference;
• the roles and what they are allowed to decide;
• the rules of the normal case and the exceptions you are keeping;
• a first scope, with what is explicitly out;
• risks already visible: dirty data, a dependency, adoption, the calendar;
• an initial architecture sufficient to start, not a final diagram;
• the hypotheses still open, and how you will check them;
• a backlog ordered by the useful path, not by technical convenience.

Analysis and architecture is how those pieces get produced before development is committed. The volume varies. A path the organisation already knows can fit in a few workshops. A business split across three tools and two sites needs more time on the floor. In both cases the finish line is the same: you know what you are building first, and why the rest waits.

Scoping does not mean freezing the project for three months. A scope that forbids learning along the way is too long. A build that starts with no answer on the exceptions is too early. Between the two there is enough to write the first line without inventing the business as you go.