I have been on the receiving end of projects where someone handed me a feature list and expected a working system. Sometimes those went fine. More often, the list described a solution to a problem that was not quite the right one, or assumed an architecture that did not fit how the business actually operated. Scoping exists to catch those mismatches before they become expensive.

Why I Do Not Start With the Code

Most developers would rather build than ask questions. But the most common cause of software projects that go over budget, miss the mark, or get abandoned is a spec that was not grounded in the actual workflow. Writing code against a bad spec is fast and expensive. A week of discovery is slower upfront and much cheaper overall.

My scoping process is not a formality to justify a proposal. It is what makes the proposal accurate and the build useful.

What the First Scoping Call Actually Looks Like

I do not come into a first call with a slide deck or a standard intake questionnaire. I come in with a few open questions and I let the answers lead the conversation. The first thing I usually ask is: walk me through what happens when a new job comes in, from the moment you first hear from the customer to the moment the invoice is paid. That one question typically surfaces more useful information than an hour of feature discussion.

What I am listening for: where the story slows down, where the person says "and then someone has to" or "and then we usually" — those are the manual steps, the workarounds, the places where the current system runs out. I am also listening for the exceptions. What happens when a job is more complex than usual? Who decides? Where does that get recorded? Exceptions reveal the edge cases that will need to be accounted for in the build.

I ask who else uses the system — and whether I can spend fifteen minutes with the person who actually does the data entry or runs the dispatch board. The operator’s view and the owner’s view often differ in ways that matter architecturally. I ask about timeline and budget because constraints shape what is realistic: a $20,000 budget on a six-week timeline changes what I can responsibly propose compared to $60,000 over six months.

What I Am Trying to Understand

The first thing I want to understand is not what you want to build. It is what problem you are trying to solve and whether the thing you think you want to build actually solves it. Sometimes it does. Sometimes there is a simpler solution, or the problem is upstream from where the client thinks it is.

  • The workflow as it actually runs today. Not the ideal version. The actual version, with the workarounds and the manual steps and the places where things fall through. I want to see how the team operates, not how the org chart says they should.
  • Who uses the system and what they need from it. A tool that works beautifully for the owner and is confusing for the staff who use it daily is not a successful project. I map the user types and their actual needs early.
  • Where data lives and how it moves. What systems are in place, what integrations already exist, what data is essential vs. redundant. Building something that has to work alongside existing systems requires understanding those systems first.
  • What success looks like, specifically. Not ‘it works better’ but: the quoting process takes less than two hours instead of six, or the team spends zero time on data entry between the CRM and the scheduling tool. Concrete, measurable outcomes.

What Comes Out of Discovery

By the end of a discovery engagement, I can produce a scope document that describes what we are building, why, what it connects to, how users will interact with it, and what the build will cost. That document is specific enough to be the basis of a contract, not a general statement of intent.

I also know, by the end of discovery, whether a custom build is the right answer or whether there is an off-the-shelf solution that fits well enough. If the latter is true, I will say so. A client who does not need a custom build is not a client I want to mislead into one.

What the Scope Document Contains

The scope document is not a proposal. It is a technical and functional specification that anyone with relevant skills can work from. Here is what a typical one includes:

1. Problem statement. One to two paragraphs describing the business problem in plain language, without feature language. What is failing, why it matters, and what a working solution needs to accomplish.

2. Current workflow. A written walkthrough of the existing process, including the workarounds and manual steps. This is the baseline we are building against.

3. Target workflow. What the same process looks like after the build is complete. Written in the same format so the delta is obvious.

4. User roles. Who uses the system and what each role needs to do. Includes access levels, device contexts, and frequency of use.

5. Functional requirements. What the system needs to do, written as behaviors from the user’s perspective. "The system must let a dispatcher reassign a job and notify the crew by SMS" is a functional requirement. "Use Twilio" is not — that belongs in the technical section.

6. Data model. The entities, their relationships, and the key attributes for each. This is the architecture blueprint in plain language before any database schema is written.

7. Integration map. Every external system the build needs to connect with, the direction of data flow, the trigger events, and the expected failure modes.

8. Out of scope. An explicit list of what is not included. This section prevents the most common source of overruns: features that were implied but never specified.

9. Build estimate. Broken out by phase or major component, with the assumptions that underpin each number. If the estimate depends on an API working a certain way, that assumption is named explicitly.

How Scope Changes Are Handled After the Document Is Signed

Scope changes happen on nearly every project. Something surfaces during the build that was not anticipated, or the client realizes a requirement was missing, or a business condition changes. The document does not prevent this. It does make it manageable.

Every change request gets evaluated against the signed scope document. If the request is genuinely new — something not in scope or out of scope — it gets quoted as a change order with its own timeline and cost impact before any work starts. If the request is a clarification of something already in scope, it gets handled without a change order and the spec gets updated to reflect the clarified understanding.

The document protects the client too. If something was in scope and I did not build it, that is my problem to fix at no cost. It makes those conversations unambiguous in both directions.

What Discovery Costs

I do not do free scoping for complex projects. Discovery is work, and it produces something of real value: a clear picture of the problem and a reliable path to solving it. My strategy consulting rate is $500/hr, and a typical discovery engagement for a software project runs a few hours to a day of time depending on complexity.

That cost comes off the table if you move forward with a build. If you do not move forward, you still have a document that describes your workflow, your requirements, and your options clearly, which is useful regardless of who you hire next. If you want a sense of what a full build costs after discovery is complete, the custom software cost page covers the ranges and what drives them.

Where Discovery Fits in the Larger Process

Discovery is the first step before any software development engagement at Salterra. It is also a standalone service for clients who want to clarify their requirements before approaching any vendor. If you want to understand what the discovery engagement produces in more detail, the discovery process page covers the outputs specifically.

If you are not sure whether a custom build is even warranted, start with the signals that off-the-shelf is failing you and work backward from there.