Andy sat in a room full of founders at Cooper Lounge Chat, a step up from pitching the idea at Start Social the week before. He had minutes to show them what we had built and explain why it mattered. We had been working on the product for three weeks. It was not finished. That was the point.
This was our second attempt at building a product as a business. The first had taught us what happens when you build for yourself — you end up with something sharp and well-engineered that nobody else is asking for. This time we did it differently. We started with a problem we had already been paid to solve, for a customer we had already helped, inside an ecosystem that would tell us honestly whether we were on the right track.
Starting with the problem, not the product
Ash Maurya has a framework he calls demo, sell, build. The order matters. You do not build the product, then demo it, then try to sell it. You demo first, sell second, build last. The logic is simple: if nobody will commit after seeing the demo, the product is not worth building yet.
We came at this from a slightly different angle. We had already done client work — rebuilding Craig's fleet CCTV platform at 4eyez, replacing spreadsheets and scattered data with a single secure application. That engagement showed us the pattern. Founders and SME owners were building with AI tools, hitting walls around security and scalability, and needing someone to make the thing fit for production.
The problem was clear. The question was whether we could turn a repeatable service into a product that did the same job faster.
The Lean Canvas as a forcing function
We filled in the Lean Canvas before writing a line of code. Not because it is a perfect tool — it is a snapshot on one page and reality is messier — but because it forces you to name the things you are assuming rather than the things you know. Who has this problem? How badly? What are they doing today instead? What would make them switch?
The canvas made us commit to answers we could test. Our customer segments in the early stages. The channels we thought would reach them. The unfair advantage we thought we had (a decade of production engineering and a genuine security background, not a thin wrapper around an AI). And the revenue model — would founders pay for a tool, a service, or something in between?
We were part of the Cooper Project at Sheffield Technology Parks, which gave us something most founders in the early stages do not have: a room full of people building businesses who would look at our canvas and tell us where it was weak. That proximity mattered more than any framework.
If you want a clear walkthrough of how to use the Lean Canvas to clarify a business idea, Hadiza Sa-Aadu's talk on The Kansas City Public Library channel covers the methodology well.
Building the demo
We built a working demo in three weeks. Not the full product. Not the infrastructure. A version that showed the core thing clearly enough that a founder watching it could say either "I would use that" or "that is not for me."
The demo covered the path from problem to outcome: a founder describes their idea, the system turns it into structured requirements, validates the logic, flags the security gaps, and shows what ready for production looks like. It was real enough to be credible and incomplete enough to be honest about where it was going.
Selling it in a room
Andy pitched at Startup Social. Twelve minutes. A room of founders, operators, and builders in the early stages of their own things.
Afterwards, he posted about it on LinkedIn and then gave a demo in front of founders on the Cooper Project. The responses were direct — people told us what they liked, what confused them, what they would pay for and what they would not.
Every piece of that feedback was more useful than a month of building in isolation.
The sequence matters because it aligns risk reduction with learning. If you build first, you are guessing. If you demo first, you are testing. If you sell first, you are validating. The earlier in that sequence you find out you are wrong, the cheaper it is to change direction.
Find your equivalent of the room. It does not have to be a formal pitch event. It can be a WhatsApp group, a Slack community, a Skool community, a subreddit, a co-working space, or a founder programme like the Cooper Project. What matters is that the people in it will tell you the truth rather than be polite.
Fill in the Lean Canvas before you build. Not because the canvas is sacred — you will change it within weeks — but because it forces you to write down your assumptions in a place where other people can challenge them.
Build the demo, not the product. Show the path from problem to outcome. Make it real enough to be credible. Do not polish it. The rough edges are part of the honesty.
Then put it in front of people and ask them to pay for it. If they will not, you have learned something valuable before it cost you six months. Andy's twelve minutes were not polished. They did not need to be. The room told us what we needed to hear.
If you are building something and want to run it past an engineer before committing further, try our app or book a free Expert Session. Thirty minutes of structured feedback on your idea, your architecture, or your demo.