If you’re considering AI for your business, someone will probably offer you a proof of concept. Before you agree to one, it helps to know what a useful proof of concept should include. In my view it should be working software that runs on your real data and does a real piece of your job. It should answer whether the idea works for your business. And it shouldn’t quietly become your production system.
Here’s how that played out with one of our clients.
The Smarter Aircraft proof of concept
We built working software for Smarter Aircraft before they had decided to work with us.
It automated one of their time-consuming document processes. We didn’t build a deck about what AI might do. We built the software and showed it to Ollie.
This is exactly what I needed! I just needed to see it in action!
Why we built it before we were hired
Ollie had already talked to a lot of people pitching AI. Most of those conversations were vague ideas and promises. I understand why that happens. It’s hard to describe software that doesn’t exist yet, and it’s even harder for a business owner to judge it.
Working software changes that conversation. Ollie could see his own process running. He could tell us what we got right and what we missed, and that gave both of us a much clearer picture of what the real system needed to be.
That’s also how our method works. We test the uncertain parts first, using the client’s own examples, because a prototype that handles the client’s worst document tells you more than any spec.
Then we throw it away
This is the part that surprises people. Once that first version has taught us what we needed to learn, we start over.
We don’t do that because it failed. It worked. We built it quickly to answer questions, and code written to answer questions shouldn’t quietly become the foundation of a production system.
This idea isn’t new. Fred Brooks wrote “plan to throw one away; you will, anyhow” decades ago in The Mythical Man-Month (discussion on the C2 wiki). AI makes that advice much cheaper to follow. The first version used to cost months, and now it can cost days.
What the second build looks like
The second build starts with everything the first one taught us. We know where the edge cases live and how the team actually works. This is where we slow down and care about the details.
For Smarter Aircraft, that became an aircraft listing management platform the business uses for its core processes. It connects document processing, listing data enrichment, and broker communications in one application (Smarter Aircraft case study).
What to ask for in an AI proof of concept
If someone offers you a proof of concept, ask these questions.
- Will it run on our own documents or data?
- Which part of our process will it actually perform?
- What question is it meant to answer?
- What happens to it afterward?
A good answer to the last question is that it gets rebuilt properly once everyone knows what’s needed.
Why clients like this approach
Clients get to see something real early, before they’ve committed to a full build. They catch misunderstandings while they’re still cheap to fix. And they end up with a production system built by people who already understand the problem.
We hate sitting around talking about vague ideas. We’d rather roll up our sleeves, build something, learn from it, and then build it right.