From AI Idea to Real App — How to Move Beyond Proof of Concept

Nick Ferguson — Head of Professional Services and AI Solutions, Strategic Group

07:34What this session covers

This isn’t really a coding session. Most of the clients we work with sit at one of two stages of AI maturity. Either they’re not quite sure what to do and are taking a first step, or there are a couple of enterprising partners, junior managers, or other people in the firm who have run ahead and started building their own things.

So we’re getting a lot of calls right now asking: how on earth do we scale this? Is it safe to scale? What do we do with the work we’ve already built? A lot of people have built something cool, whether it’s an agent, an application, or a tool, and they want to get it out to the whole team. Is that safe? How much will it cost? What other tools do we need?

I want to walk you through those steps. Really, it comes down to the three questions you need to ask yourself to build a working AI app, and the traps to avoid along the way. There’s a tool I’ll get you to play with called the AI field guide, which lets you explore any idea you’ve got and see how much effort it would take to turn it into something useful.

09:50Why AI ideas actually fail

If you take one thing away from today, it’s this: most AI ideas aren’t failing because of the model. The tools you can buy with a credit card for thirty bucks a month or more are genuinely excellent these days. They fail because the problem statement wasn’t clear enough, the scope was too ambitious or too muddy, and often because of the data.

And it’s not data in the way you’d think. It’s not usually about access to data. It’s about describing the data, finding where it lives, and making sure your AI can actually reach it. There are lots of little stumbling blocks. Defining these things up front, whether that’s in your own head or sparring with your chosen AI to flesh it out, saves you a lot of pain, a lot of time, and a lot of tokens.

If the failure is upstream of the build, then the work has to be upstream too.

11:21Where firms are at today

The word I’d use is experiments. Lots and lots of experiments. Are we using Perplexity or Claude? ChatGPT or Copilot? A combination of all of them? What about building agents, or little AI tools running with a BAS helper agent or inside a practice management tool?

But we’re not seeing much scale. A lot of things are trapped at the individual user or peppered across the business. The one exception is firms that have deployed Copilot or ChatGPT as a firm-wide rollout. Some are quite far through on that part of the journey.

So there are lots of early wins and lots of cool things working, but they often feel fragile. The hard part comes next: how do you take something that worked for me and turn it into something that works for the whole firm? That hard work comes down to three questions. What’s the problem we’re trying to solve? What’s the scope of the build? And what’s the structure of the data we need? Get those three right and your AI will work well, quickly, and ironically it’ll be quite easy to build too.

16:08Question one: define the problem

If we’re too vague, the AI will guess and make things up. The AI won’t fix unclear thinking. Vague framing produces disappointing outcomes. So ask three questions up front.

First, what outcome are you solving for? Many of you said “onboarding” or “reconciliation” or “tax workpaper reviewer.” But there’s a task and there’s an outcome. With onboarding, the outcome might be: we want to automatically onboard new clients so they’re ready to go in our systems. Being specific about the actual outcome moves you away from the task and toward what you’re really trying to achieve. AI is clever; it can suggest different ways to get there. The more specific your aim, the more value you get.

Second, what data do you need to achieve that outcome, what’s the source, and where does it live right now? For onboarding, a lot of that data might already be sitting in your practice management solution, in a client email, or in a survey form. If you know what you need and where it lives, you can often just connect two Lego blocks together and hand them to the AI immediately.

Third, knowledge and context. What else matters? You’ve got the data, but you also have AML requirements to meet. You don’t want to spam the client because customer experience matters. And maybe it needs to trigger something in your practice manager to link into another business process. An outcome, a data source, and any constraints or knowledge: all really useful for the AI to know before it starts building.

19:27Use AI to sharpen the brief

This is the first takeaway. Spend the time to figure this out. The hot tip is to use your AI to explore those three questions. Ask it to keep asking you questions about your statement until you’re happy it’s clear. If you get this part right, it’s probably the single most valuable thing you’ll take from this talk.

Skip it, and you’ll keep iterating again and again on little things when you could have got it right in the first prompt. When I’ve skipped this step, it’s gone from “oh no, I didn’t mean that, I meant this” to “can you redo that part” fifteen or twenty times, a couple of hours later, fixing the wrong parts of the problem.

Compare two prompts. “Build an AI to help with your clients” produces something, but it says nothing about the outcome, the data, or the owner. Now try: “Draft client-ready replies to a tax query. Use prior firm advice and our tone guidelines.” Straight away the AI can ask the right questions: Where is your prior firm advice? Do I have access? Where are your tone guidelines, is there a brand kit? What do you mean by client-ready? You’ll get a much better result.

21:44The localhost trap

There’s a tweet I love. Two people proudly share an app they built, posting a link, trying to show it off publicly. The telling issue, the giveaway about how much they actually understand what they built, is one word: localhost.

Localhost is where these two have built and deployed an application, just like any of us can, using Claude or ChatGPT or something else. It probably works perfectly for them. But if anyone clicks that link, nothing happens, because it’s running locally on their own computer.

There are barriers like this for all of us. The first time you build something and try to share it with a colleague, the same thing happens. Even if you’ve spent months iterating and it works beautifully, the moment you try to share it with your partner or your board, your application is missing parts. It works for you, but it can’t scale.

You built it, it solves the problem, it impresses you. But you tested it on your account, with your data, your permissions, and your context. The moment someone else tries to access it, they can’t log in, or it doesn’t have the data you have. And there are other traps beyond localhost: identity management, storage, scale, compute, all the things that arrive when you move to an enterprise solution.

24:53Question two: scope the build with DRAFT

So how do you avoid that? Scope the build up front. We use a framework called DRAFT, which is what the AI field guide tool runs through. It answers five questions.

Who is it for? If it’s just for you, you can ignore half of what we’re discussing today. It runs on your phone, your computer, your inbox. If it’s for your team or your whole company, that complicates things and you need more tools.

Records, or what data will it touch? Publicly available information, we can do almost anything. Firm IP brings security constraints. Confidential data means the tool has to be built to handle it, with the complexity that brings.

Autonomy. Are we building an agent that can click and do things itself, or something that just drafts for us? The level of autonomy strongly shapes complexity.

Fit. How does it sit alongside or inside your other systems? Is it standalone, or does it hook into your XPM, your SharePoint? Other systems mean getting permission to pull data out.

Transfer. Who owns it after you’ve built it? You run a pilot for two months, then hand it over to your IT provider, your boss, someone else. That determines how much documentation and other work you need.

27:12Walking the tool through an onboarding assistant

Let’s run a client onboarding assistant through it. The “D” is who it’s for. An onboarding assistant can’t just be for me; the point is it’s for others, so maybe the whole tax team. Records: not public information, so client data. Autonomy: you’d probably want to review and sign off what it does rather than let it act. Fit: it needs to talk to your client systems, so that’s a middle level. Transfer: you might hand it to the IT team.

At that point the tool spits out an estimate of how long it might take to build. With those choices, this looks like a project: a couple of months, some real engineering, and you’d probably need a developer.

The tool also gives you suggested next steps, a shopping list of what you’ll need, a couple of watch-outs, and a risk profile. If it’s hard to build, there’s a “love it but simpler” button that steps things down. Click it as many times as you like until you reach something you could build right now. To be clear, the tool is de-identified: I don’t get a copy of your data, only a count of how many people complete it. You can download a PDF at the end.

At the simplest level, a free or paid Claude, ChatGPT, or Copilot account is more than enough. A screenshot of what you’re trying to build plus the description you’ve written is all your AI needs to get started. Push it back up to “the whole team needs it” and the requirements climb: a paid Claude with API access and extra costs on top.

31:38A worked example: engagement health check

Here’s one I prebuilt this morning with Claude, a tool that checks engagement health across clients. Are we profitable? Are we doing the right thing? Should we be paying more attention to certain clients?

It’s the kind of tool you can build in a couple of minutes with Claude or ChatGPT. I take some sample data, drag in a CSV, and it immediately runs analysis on the work. Imagine any local file, any client file you’ve downloaded.

This is the localhost pattern in practice. The file actually sits on my OneDrive. It has the appearance of a website, and in a sense it is, because I’ve opened it in my browser, but it doesn’t go anywhere. As a personal productivity tool, any calculation you want, you can run this locally on your own device pretty safely. It’s not sending the data anywhere, and you can reload it with any data type.

This was built with Claude Code specifically. Different AIs have different tools inside them. Claude has Claude Design, Claude Code, Claude Cowork, and chat. Most of them have a chat application that can write code too, but Claude Code is what produced this HTML file I can run locally. There are four files here: the practice health check itself, the full prompt (which I’m happy to share, so you can paste it into your own Claude and rebuild this), and two sample datasets.

36:50When local stops being safe

Big asterisk. This is safe for me right now because it’s hosted locally on my own device. The moment you scale it to other people or other systems, it’s no longer safe without extra controls around the client data, because you need to control where that data goes.

If I want this to live on my computer and yours, or on both our phones, I now need to answer: Where is the data going to be stored? What’s the database? What rules does it need? How do I prove that someone logging in is who they say they are, so data doesn’t leak somewhere else? Those are extra steps, and the DRAFT tool surfaces them.

One of the things you’ll need is an enterprise large language model with appropriate data-handling clauses. For example, Copilot in Microsoft 365 Premium meets enterprise data protection, the same high standard as your inbox, and it’s very safe. Claude comes in different tiers. By default the Pro tier shares and trains on your data, so building with client data there risks exposing what you shouldn’t. Step up to Team or Enterprise, where you’re paying for five or twenty or more licenses, and you get the right level of data protection. You need to check this against your own policies and data.

The point is there’s a process you can follow. Run the DRAFT exercise and it gives you suggestions that lead to the right next questions. There’s a second step too: if you’re going enterprise, it’ll start telling you which tier of Claude or Microsoft you need, or what type of Azure or AWS database. If that’s gobbledygook right now, that’s fine. Just know that as you scale, you need more tools than your AI alone.

39:59Validate small, then scale

To bring it back: understand the scope of what you’re building by asking the right questions. My best advice is to validate your problem statement by building something just for you. Scale it down as far as you can, use the tool to step it down a few levels, build it for yourself, confirm it works, and then think about how you scale back up. Building for yourself, you can probably do in an evening. Building for the whole team might take a month or two. There’s a big difference.

40:49Get the data right, your biggest advantage

The final point comes back to data, and ironically this is where accountants are miles ahead of other industries. You already have really good data. You’ve got spreadsheets that express exactly how to do a calculation, workpapers, financial models you’ve honed over years. Compare that to the average recruitment team or HR function, where people don’t have data they’ve built and understand at their fingertips. You have a big advantage. You probably have excellent calculations available and you understand how the data fits together. If FY24 feeds into FY25, you’ve already built the calculations that hold that relationship.

The data needs attributes. Finance areas, dates, times, text fields, defining those correctly matters. So does format. Is it a table inside an Excel spreadsheet? Multiple tables feeding each other? A pivot table? I’m being deliberately specific about Excel because it’s an excellent way to build out your data model and check everything works.

And define your terms. If something passes through a process and passes or fails, you need to decide that. When you reach the moments that matter, when you want the AI to visualize results, it helps to define how it determines pass or fail, or whether it’s a three-point scale: pass, neutral, fail, or good, neutral, not good.

You have the ability to build powerful Excel spreadsheets, surveys, and database exports that behave exactly how you want. Earlier we talked about defining your problem statement; this is the source component of it. “This is the exact financial model I want you to use, Claude.” Putting the work into your model, your survey, your data lets the AI build exactly what you want and turn it into an application quickly. If you’ve put the thinking into how the calculations should behave, rather than relying on the AI to invent a solution, you immediately improve your results in both speed and accuracy.

45:02What scaling actually requires

We’ve all got great ideas, dozens in the chat earlier. Moving to something that scales means getting past the stage where one person has one prompt and a document that works for them and then stalls. You need the components from the DRAFT tool.

It needs a database where the data lives; it can’t be just your browser forever. It needs to live somewhere central so more than one person can access it. It needs authentication: when I’m logged into my own Claude, it knows it’s me, but to share it with a team, the application needs a way to verify each person is who they say they are. It needs version control, so you can roll back a mistake or make a change without rewriting the whole app or breaking it. Once deployed, it needs monitoring so you know whether it’s working or broken. And it needs governance: who owns it, who’s accountable.

As you reach that scaling point, and that conversation with your partners about the cool thing you built, these are what expand your investment decision. It’s not just the thing you coded; it’s how you make it real for the rest of the business.

47:15What good looks like

A few success criteria worth a screenshot. A solution, not an experiment, needs a use case and an owner. Your data input and structure must be defined correctly. It needs to produce repeatable, dependable outputs, so think about how you’ll test: does it produce the same thing over and over, or something different every time? It needs to work where the people are, in the workflow. And it needs a way to be governed over time.

So stop asking what AI can do. Start asking what problem we’re solving and what good would look like. Scaling and success come from a really good definition of your problem, getting the data right, and deciding what’s actually worth building.