How to scope an AI project so it actually ships

There is a tweet I keep coming back to. Two people, proud of the AI app they had built, sharing the link publicly to show it off. The word that gave them away was localhost. The app lived on their own machine, ran perfectly for them, and did nothing for anyone who clicked the link. I open most conversations with firms about scaling AI on that story, because the same pattern shows up in almost every practice I walk into. I ran a session at The Firm's AI in Practice Summit on this issue, and this is the version of the argument I want practice owners to sit with.

Most AI projects that fail in firms are not failing because the model was inadequate. The tools you can buy for thirty dollars a month are genuinely excellent. Projects fall over upstream of the build. A fuzzy problem statement. A scope that swelled from a personal productivity tool into an enterprise deployment somewhere along the way. Data that has never been described, structured, or checked to see if the AI can actually reach it. Those are the three places AI projects go wrong, and the model has almost nothing to do with it.

The work has to happen upstream, because that is where the failure happens.

Question one: what problem are you actually solving

The first question is deceptively simple. What outcome are you solving for.

Most firms answer with a task word. Onboarding. Reconciliation. Tax workpaper review. The AI takes that word, guesses at what you might mean, and produces something disappointing. What you needed to say was something like: automatically onboard new clients so they are ready to go in our systems, using our existing intake form and practice management data, without spamming the client in the process.

That is a real brief. It has an outcome, a data source and a constraint. When you hand that to Claude or Copilot or ChatGPT, it can ask you the right questions immediately. Where is the intake form. What does ready to go mean. What counts as spamming. You get a much better result on the first pass and save yourself twenty iterations later.

The habit worth building is using your AI to sharpen your own brief. Ask it to keep asking you questions about the problem statement until the statement is clear. That single habit will save you more time than any tool you can buy.

Question two: how much are you actually trying to build

The second question is scope. The framework I use is called DRAFT, and it asks five things.

Who it is for. A tool just for you carries minimal constraints. A tool for the whole tax team climbs the requirements ladder fast. Records: what data will it touch. Public information is easy. Client data brings security constraints. Autonomy: whether it is a drafting assistant or an agent acting on its own. Fit: standalone, or hooked into your XPM and SharePoint. Transfer: who owns it once you have built it, because a pilot handed to IT looks very different from a tool sitting with one partner.

The most useful thing DRAFT does is show you when you are trying to build too much. An evening project for one person can become a two-month build with real engineering the moment you decide the whole team needs it. Both are legitimate. They are different projects.

The advice I keep giving practice owners is to validate the problem by building something just for you first. Scale it down until you can build it in an evening. Confirm it works. Then think about how to scale it up.

The localhost trap

The localhost story lands with practice owners because they have all had this happen. You build something in Claude or ChatGPT. It works beautifully. You test it on your own account, with your data and your permissions. You demo it to the partners. Everyone is impressed.

The moment you try to share it, the app falls over. Someone else cannot log in. The data is not there. The AI cannot reach the file. What worked for you on localhost cannot scale, because scaling requires infrastructure the AI does not build for you.

Once the whole firm needs it, you need a database somewhere central. Authentication that verifies who is logging in. Version control so you can roll back a mistake. Monitoring so you know when it is broken. Governance so someone actually owns it. You also need an enterprise tier LLM with data-handling terms that keep client data out of model training. Copilot in Microsoft 365 Premium meets that standard. Claude Team and Enterprise meet that standard. The default consumer tiers train on the data you feed them, which becomes a compliance problem the moment client information is involved.

Keep building. Just know which building you are actually doing.

The advantage accountants have

The last point is the one I want practice owners to hold onto. On data, accountants are miles ahead of most industries.

You already have workpapers that express exactly how a calculation should behave. Financial models refined over years. Spreadsheets that show FY24 feeding into FY25 with the relationships already built. Compare that to the average HR or recruitment team, and the gap is enormous. Feed those existing artefacts to the AI as the source of truth for how the calculation works. Do not let the AI invent the logic. It will guess. It will hallucinate. It will improvise.

The moment you hand it your model and say this is the way I want you to do this, the output gets dramatically faster and dramatically more accurate.

The message I want to leave you with is this: stop asking what AI can do, and start asking what problem you are solving and what good would look like. The teams pulling ahead have done the upstream work everyone else keeps skipping. The model was never going to be the differentiator.

You can watch the full session here.