We Built a Quiz Engine. Not for Clients. For Us.
The idea of an agency becoming a product company is one of those things that sounds smart in a podcast episode and is genuinely hard to execute without quietly wrecking the business that pays the bills.
I have seen it done badly. Agency owners who decide they are going to build a SaaS product, pull their best people into it, start shipping slower for clients, and eighteen months later have neither a functioning product nor the clients they had before.
I have also seen it done well. The difference is almost always the same thing: the businesses that make this transition successfully build tools they already needed for themselves, then package them. They do not go looking for a market to serve. They solve a problem they live with every day, and then discover — sometimes to their own surprise — that other people have the same problem.
That is what we are doing with our quiz engine.
The Problem We Kept Solving Manually
If you have worked in digital marketing long enough, you know the lead qualification problem intimately.
Someone fills in a form. They get put into a nurture sequence. Your sales team works through a list of qualification questions on the call — budget, timeline, decision-making authority, current situation, what they’ve tried. You are 12 minutes into a call before you have enough context to know whether this person should be talking to you at all.
Multiply that by however many leads you are generating each month. Multiply it again by the cost of your sales team’s time. And then consider that a significant portion of those calls end with “thanks for your interest, not quite the right fit for us right now” — which is polite for: we both just wasted 20 minutes.
We were helping clients build lead qualification processes on their websites, in their email sequences, in their onboarding flows. Every time, we were building something similar from scratch in a new tool, for a new client, with a new brief. Different platform, same problem, same logic, slightly different execution.
That is the moment a product starts to make sense. When you catch yourself solving the same problem for the fifth time and thinking: we should have a system for this.
Why We Did Not Build for a Market First
Here is the temptation when you get to that moment: you google “quiz software” and you find a dozen competitors, and then you go talk to a product designer and start thinking about market positioning and user personas and pricing tiers.
I have done enough of that to know it is the wrong place to start.
The problem with building for an imaginary market is that you do not actually know what the tool needs to do. You know what you think it needs to do, based on your best guess at what users will want, filtered through your assumptions about the problem. By the time you build, validate, iterate, and find product-market fit — if you ever do — you have spent two years and considerable money discovering something you could have learned in three months by solving your own problem.
We have a very concrete problem. We understand it in detail. We know what “working” looks like because we do this work every day. That is the best possible starting point for building a product.
So we started there.
What We Built and Why
The quiz engine we are building is designed to do one thing well: help users self-qualify through a series of adaptive questions that route them to personalised outcomes.
For us, that means a tool we can use with our own clients — for lead qualification, for onboarding, for content personalisation based on where someone sits in their decision process.
But the architecture is built to be deployable. The same engine that qualifies a B2B marketing lead works for a health brand segmenting customers by wellness goal, or an insurance company routing prospects to the right product before the first call.
We are building through phases.
[NEEDS CLIENT INPUT: Specific phase milestones and current phase progress — add before publishing]
Each phase is scoped to something we can ship without disrupting client delivery. This is the discipline that makes the agency-as-product-company model work: you cannot let the product become an excuse to underserve the clients who are funding it.
The rule we set ourselves: 100% of scheduled client delivery must remain on time and on standard during every development phase. If a development sprint would require pulling capacity from a client commitment, the sprint moves. The product is not more important than the clients who are paying for it.
This is harder than it sounds. Product development creates its own momentum — there is always a feature that feels urgent, a bug that demands attention, a decision point that wants the team’s focus. Holding the line on client delivery requires actively choosing, every week, not to let the product steal the attention it wants.
The “Eat Your Own Dogfood” Principle
There is an old tech industry saying: eat your own dog food. Use the product you build. Live with its problems. Notice what is broken.
We are not building a quiz engine and then figuring out how to use it. We are using the quiz engine — for our own qualification process, for our own client onboarding — as part of the build. Every time we use it internally, we learn something. A question that felt clear in the spec feels awkward when you are actually filling it in. A routing logic that seemed elegant in the diagram creates edge cases in practice. A result page that should have felt helpful just feels flat.
These are not problems you find in user testing. You find them by using the thing you built, with real decisions attached, when the stakes are real.
The feedback loop is short because the user is us. We fix the thing we just noticed was broken. We ship again. We use it again.
This is the underrated advantage of building tools for your own process: you have access to the most demanding, most honest user research possible. Your own experience of the product every working day.
When to Package an Internal Tool as a Product
Not every internal tool should become a product. Some tools are too idiosyncratic — they solve a problem that exists specifically because of how your business is structured, and nobody else has that structure. Some tools are effective precisely because they are rough and fast — a spreadsheet that you would be embarrassed to put in front of a customer is still a useful spreadsheet.
The signals that suggest an internal tool is worth packaging:
You solve the same problem repeatedly across clients. If you are rebuilding essentially the same tool for every engagement, there is probably a productizable pattern underneath the customisation.
The tool is valuable because of the logic, not just the execution. If what makes the thing work is a particular decision framework or sequence of questions or routing logic — and not just the fact that you built it carefully — then that logic can be packaged.
Your clients ask if they can keep it when the engagement ends. That is the clearest signal. When clients want to own the thing you built for them, there is a product in there.
The quiz engine passes all three. We build qualification and segmentation flows for multiple clients. The value is in the adaptive questioning logic, not just the implementation. And yes, clients have asked.
The Revenue Model Question
I want to be honest about something, because I think a lot of agency owners thinking about productization underestimate this part.
Building a product while running a service business does not automatically become a revenue source in year one. It requires sustained development investment, a go-to-market strategy, pricing decisions, support infrastructure. These are not agency problems — they are product company problems. And they are different skills.
What the product does in year one, if you are doing it right, is improve the quality and efficiency of your service delivery. The quiz engine makes our qualification process better. It makes our clients’ qualification processes better. It creates a differentiator in how we work.
That is real value, even before a single product license is sold.
The evolution from service to hybrid to product company is not a switch you flip. It is a progression. You build the tool. You use it. You refine it through use. You demonstrate its value in client work. Eventually the product becomes a standalone offering, then maybe the primary business.
But it starts with solving a problem you actually have.
What This Means for Agency Owners
If you are running a service business and thinking about productization, the question is not “what product should I build?” It is “what do I keep building manually that I should systematize?”
Look at your delivery process. Where do you solve the same problem more than twice a year? Where do your best people spend time on work that feels like it should be automated? Where do clients always ask “can we have a version of this?”
That is where your product is hiding.
Do not build it for an imaginary market. Build it for yourself. Use it daily. Improve it through use. Then, when it works well enough that you would be proud to put it in front of a client — put it in front of a client.
The product market will find you faster than you will find it.
