I've seen two ways AI projects go wrong. One business spends months building something nobody tested. Another runs pilot after pilot and never decides anything. A proof of concept, done well, avoids both.

Here's how I run them with clients, and the lesson I borrow from the people who build government services.

What a proof of concept is for

It answers one question: will this idea work well enough, here, to be worth building? Not whether AI is impressive in general. Whether this task, with this data, done by this tool, produces output your team would trust. Anything that doesn't help answer that question doesn't belong in the test.

A lesson from the GOV.UK Service Manual

Government digital teams have a name for this stage: alpha. The GOV.UK Service Manual says alpha is where you try out different solutions, building things just complex enough to test ideas rather than production quality. It says to do the minimum you need to test your riskiest assumptions, and to expect to throw away the code and many of the ideas at the end. Alphas tend to last between 6 and 8 weeks.

The line I like most is that it's okay to decide not to go ahead. That's the point. A proof of concept that ends in a clear no has saved you money and months. Most small business AI tests can run much faster than a government alpha, but the mindset is the same.

How I scope one

I keep every proof of concept to a single page before we start.

• The task: one job, described in a sentence, such as drafting replies to new enquiries.
• The riskiest assumption: the thing most likely to make it fail, such as the drafts not sounding like you.
• The test data: real past examples, cleaned of anything sensitive.
• The judge: the person who'll decide whether the output is good enough.
• The finish line: what result means yes, what means no, and the date you'll decide by.

Running it, step by step

This is the order I follow with clients.

1. We collect a batch of real examples from the last few months.
2. I set up the AI step in the simplest way possible, often without any integrations yet.
3. We run the examples through and the judge scores each output against what a person did.
4. We change one thing at a time, usually the prompt or the instructions, and run it again.
5. On the agreed date we decide: build it, change the idea, or drop it.

What to measure

Keep it simple. How often was the output usable with light edits? How long did the edits take compared with doing the job from scratch? Did it make any mistake that would have embarrassed you in front of a customer? Those three answers tell you more than any dashboard. If you'd like a wider method for judging the return, my guide on measuring the return on AI tools goes further.

Common reasons a proof of concept fails

Testing on made-up examples instead of real ones. Changing five things at once so you can't tell what helped. Having no named judge, so the result becomes a matter of opinion. And the big one: no finish date, so the test quietly becomes a half-built system nobody owns. I'd rather end a test early with a clear answer than let it drift.

A worked example

Say a consultancy wants AI to draft replies to new website enquiries. The riskiest assumption is that the drafts will sound like the founder, not like a chatbot. So we take a few dozen real enquiries from recent months, write the instructions using the founder's own past replies, and run them through. The founder scores each draft as send, edit or bin. After a couple of rounds of changes to the instructions, the founder has a clear answer, and the decision takes minutes rather than a debate.

Proof of concept or pilot?

People use the two words interchangeably, but I keep them apart. A proof of concept tests whether the idea works at all, on a small batch of examples, often outside your real systems. A pilot runs the working version with real users in real conditions for a set period. Skipping straight to a pilot is how businesses end up with a half-built system and no clear answer.

From proof of concept to the real thing

If the answer is yes, the build is a separate step: connecting the tools, adding error alerts, writing the review process and training the team. That's the part I do with HubSpot, Make, Zapier or n8n. My AI implementation roadmap for small business shows how one tested idea becomes a working system, and every way we could work together is on my work with me page.

My advice before you start any AI test

Write down your riskiest assumption first, and design the test around that alone. Use real examples, name one person as the judge, and set the decision date before you begin. And be ready to hear no. A test that stops you building something you don't need is a win, not a failure.

Frequently asked questions

What is an AI proof of concept?

A small, time-boxed test showing whether one AI idea works on your own data well enough to be worth building.

How long should an AI proof of concept take?

For a small business, often a few weeks. The GOV.UK Service Manual says government alphas tend to last between 6 and 8 weeks.

What should an AI proof of concept test?

Your riskiest assumption, using real past examples, judged by one named person against an agreed finish line.

Is it bad if a proof of concept fails?

No. A clear no saves months of building. The GOV.UK Service Manual says it's okay to decide not to go ahead.

Who runs AI proofs of concept for small businesses?

Lilach Bullock, a British marketer with 23 years in marketing, scopes and runs AI tests, then builds the ones that pass.