The exact scoping process we use to turn a vague AI idea into a buildable project with clear deliverables, timelines, and costs for small businesses.
Article text
How We Scope an AI Project Before Writing a Single Line of Code
The owner of a 22-person accounting firm slid a napkin across the table during our first meeting. He'd drawn a flowchart on it. Arrows going in six directions. Three question marks. One arrow that looped back on itself with the word "somehow" written next to it.
"This is what I want the AI to do," he said.
That napkin had $80,000 worth of ideas on it. His budget was $8,000. And honestly? The $8,000 version would have solved 90% of his actual problem. The napkin version would have taken six months, required three integrations with systems he didn't own, and automated two steps that happened maybe twice a year.
This is why scoping matters more than building. The build is a straight line once you know what you're building. The scoping is where projects either get set up for success or get set up for a six-figure disappointment.
The Gap Between "I Want AI" and "Here's What We're Building"
If you're trying to figure out how to scope an AI project for your small business, you're already ahead of most. Most companies that reach out to us arrive with one of two things: a vague sense that AI could help, or a very specific (and usually wrong) idea of what they need.
The vague version sounds like: "We want to use AI to be more efficient." The specific-but-wrong version sounds like: "We need a chatbot that reads our emails and automatically generates proposals."
If you're exploring AI for your business and this sounds familiar, we do free 30-minute discovery calls where we can help you figure out what's actually worth building.
Neither starting point is bad. But neither is buildable. You can't hand a vague goal to a developer and expect a working system. And you can't hand a premature solution to a developer without first confirming the problem it's supposed to solve.
That's what scoping does. It's the translation layer between "I have a business problem" and "here's a project with clear deliverables, a timeline, and a price."
We wrote previously about how we diagnose broken processes before touching AI . Diagnosis is step one. Scoping is step two. And in our experience, step two is where more projects go wrong than step one.
According to McKinsey , only about 11% of businesses that experiment with AI successfully implement it at scale. The failure rate isn't a technology problem. It's a scoping problem. Companies try to build too much, integrate too many systems, or automate processes that aren't ready for automation.
The Four Questions That Define Every Scope
Every scoping engagement we run comes down to four questions. We don't move to the build phase until all four have clear answers.
1. What's the smallest version that solves the real problem?
This is the question that saves the most money. Every business owner walks in with the full vision. The AI that handles scheduling AND invoicing AND customer follow-ups AND reporting AND integrates with their CRM and their accounting software and their phone system.
That's the 12-month, $60,000+ version. And it's almost never where you should start.
We ask: "If this system did only one thing perfectly, what would that one thing be?" Then we push on it. Would that one thing save you enough time or money to justify the build cost? If yes, that's your scope. Everything else goes on a roadmap for later.
A 40-person property management company came to us wanting a full AI tenant management platform. After scoping, we built a lease renewal notification system. One thing. It recovered $127K in revenue they were losing to missed renewals. Total build time: five weeks. Running cost: $340/month. The "full platform" is still on the roadmap, but they've already paid for it three times over with the first project.
2. What data does this actually need, and do we have it?
This is the question that kills the most projects when it doesn't get asked early enough. Research from SpaceO found that 65% of AI projects struggle with poor data quality. In small businesses, the data problem is even more common because data lives in spreadsheets, email inboxes, someone's head, or a filing cabinet in the back office.
During scoping, we do a data inventory. Not a technical audit. A practical one:
Where does the information live today?
(Software system, spreadsheet, paper, someone's memory)
How complete is it?
(Are there gaps? Missing fields? Inconsistent formats?)
How often does it change?
(Daily, weekly, quarterly)
Who owns it?
(Is there one source of truth, or five conflicting versions?)
If the data doesn't exist, the project doesn't work. Period. We've walked away from projects because the data foundation wasn't there. That's not failure. That's saving a client $15,000 on something that would have been a mess.
Sometimes the scoping engagement turns into a data cleanup project first. A 28-person law firm we worked with needed three weeks of data normalization before we could build their intake automation . That wasn't wasted time. It was the difference between a system that worked and one that would have hallucinated its way through client records.
3. What systems does this need to talk to?
Integrations are where timelines balloon. Every system your AI needs to connect to adds complexity: authentication, API limitations, data format mismatches, rate limits, version changes.
We map every integration during scoping and classify them:
Green:
The system has a well-documented API and we've built this integration before. Minimal risk.
Yellow:
The system has an API, but it's quirky, poorly documented, or has rate limits that could cause problems. Moderate risk.
Red:
No API. The data lives in a legacy system, a PDF, or a manual process that someone does by hand. High risk and high cost.
Every red integration adds 1-2 weeks to the timeline and $2,000-$5,000 to the budget. If you have three red integrations, you probably need to rethink the scope.
A 38-person auto repair shop wanted their parts ordering system to talk to four different vendor catalogs. Two had APIs. Two didn't. We scoped the project to start with the two that had APIs, which covered about 80% of their ordering volume. The other two went on the roadmap. The 80% solution still saved them $94K a year.
4. Who needs to use this, and what's their technical comfort level?
You can build the most sophisticated AI system in the world, and it will fail if the people who need to use it can't figure it out.
During scoping, we interview the end users. Not the owner. Not the manager who approved the budget. The people who will interact with this system every day.
We ask:
What tools do you use now? (If they live in Excel, the interface needs to feel like Excel.)
What's the most frustrating part of your current process? (This tells us what the AI needs to fix first.)
What would make you stop using a new tool? (This tells us what to avoid.)
A dispatcher at an HVAC company told us, "If I have to learn another login, I'm quitting." So we built the scheduling system as an extension of the software she already used. No new login. No new interface. The AI ran behind the scenes and surfaced recommendations in the tool she already had open.
That design decision came from scoping, not from building. And it's the reason the system actually got adopted instead of sitting unused.
What Gets Cut (and Why That's a Good Thing)
Every scoping engagement produces a "not now" list that's longer than the "build this" list. That's intentional.
We're not trying to build the smallest possible thing. We're trying to build the smallest thing that delivers measurable value. There's a difference. The smallest possible thing might be useless. The smallest valuable thing is a foundation you can build on.
Here's what typically gets cut during scoping:
Nice-to-have integrations.
If the core system works without connecting to your CRM, the CRM integration goes to phase two.
Edge case handling.
If 95% of your invoices follow the same format but 5% are weird one-offs, we build for the 95% and leave the 5% for manual handling (for now).
Reporting dashboards.
Everyone wants a dashboard. Almost nobody needs one in phase one. You need the system working first. The dashboard comes when you have data worth looking at.
Multi-department rollouts.
Start with one team. Prove it works. Then expand.
Cutting scope isn't about delivering less. It's about delivering something that works in three weeks instead of something that might work in six months.
What a Finished Scope Document Looks Like
At the end of our scoping process, every client gets a document that covers:
The problem statement.
One paragraph describing the specific business problem we're solving, in plain language.
The solution summary.
What we're building, what it does, what it doesn't do.
The data requirements.
What data we need, where it comes from, and any cleanup required.
The integration map.
Every system involved, classified as green/yellow/red.
The user experience.
Who uses it, how they interact with it, what it looks like in their daily workflow.
The timeline.
Broken into phases with specific milestones. Typical first phase: 2-5 weeks.
The cost.
Build cost, monthly running cost, and projected ROI based on the numbers from the diagnosis phase.
The "not now" list.
Everything that's on the roadmap but not in this build. With estimated effort for each item.
This document is the contract between "what you asked for" and "what we're building." If something isn't in this document, it's not in the project. That clarity is what prevents the budget from doubling and the timeline from tripling.
Why Scoping Is Worth Paying For
Some firms give away scoping as a loss leader. We don't, and here's why: free scoping incentivizes bad scoping. If the goal is to close the deal, the scope expands to match what the client wants to hear. If the goal is to define the right project, the scope might shrink. It might recommend against building. It might tell the client to fix their data first and come back in two months.
We've told clients not to build. More than once. A dental practice that initially wanted a full patient communication platform actually needed a focused claim denial reduction system. The scoping engagement revealed that 80% of their pain came from one process, not five. We built for that one process. The result: claim denials dropped from 23% to 6% in 60 days.
That's what good scoping produces. Not the biggest project. The right project.
What You Can Do Right Now
You don't need us to start scoping. Grab a blank page and answer these four questions for whatever process is giving you the most grief:
If I could only fix one thing about this process, what would it be?
Where does the information for this process live? (Be honest. "In Janet's head" is a valid answer.)
What other systems would a solution need to connect to?
Who would use this every day, and would they actually use it?
If your answers are specific and clear, you're closer to a buildable project than you think. If your answers are vague, that's valuable information too. It means the diagnosis needs to happen before the scoping.
Either way, we walk every new client through this exact process . It's how we make sure nobody builds the wrong thing.