Why Every Consultant Should Build a Product (Even a Small One)

For most of my career, I've sold time. Hours of consulting, days of workshops, weeks of project delivery. The maths is simple: work more hours, earn more money. Stop working, stop earning.

This is the consulting trap. And almost every independent consultant I know is stuck in it.

In early 2026, I built Scorafy - a SaaS product that generates AI-powered assessment reports. It took about six weeks from concept to live product. And it fundamentally changed how I think about my consulting business.

Here's what I've learned, and why I think every consultant should build something - even if it's small.

The time-for-money ceiling

Consulting has a hard ceiling. There are only so many hours in a week. Even at premium rates, your revenue is capped by your availability. Take a holiday? Revenue drops. Get sick? Revenue drops. Want to scale? You either raise rates (which has limits) or hire people (which changes your entire business model).

The problem isn't that consulting is bad. It's that consulting alone is fragile. You're one illness, one lost client, one slow quarter away from a cash flow problem.

A product - even a small one - breaks this pattern. It generates revenue while you sleep, while you're on holiday, while you're delivering consulting work to other clients. It's not passive income (nothing truly is), but it's decoupled income. The revenue isn't tied to your calendar.

How building Scorafy changed my consulting

The most surprising benefit wasn't the product revenue. It was what happened to my consulting practice.

Credibility jumped overnight. When I tell a potential consulting client that I've built and launched a production SaaS product, the conversation changes. I'm not just advising on technology decisions - I've made them, lived with the consequences, and shipped the result. That's a different level of authority than someone who only advises.

My advice got better. Building a product forces you to confront every decision that your consulting clients face: architecture choices, pricing models, payment integration, user onboarding, marketing, support. I experienced the full lifecycle, not just the strategy phase. My consulting recommendations are sharper because of it.

I attracted better clients. People who find me through Scorafy tend to be builders themselves - founders, product managers, technical leaders. These are exactly the kind of clients I want for consulting work. The product acts as a filter, attracting people who value execution over theory.

I have a case study that sells itself. Instead of talking about hypothetical capabilities, I can point to a live product and say "I built this in six weeks using AI-assisted development. Here's how I can help you do the same." That's more compelling than any pitch deck.

The compounding advantage

Consulting revenue is linear. You do work, you get paid, the transaction ends.

Product revenue compounds. Every feature you add makes the product more valuable. Every user you acquire can refer others. Every month of operation generates data, testimonials, and insights that make the product better. The work you did six months ago continues to generate value today.

And the knowledge compounds too. Building Scorafy taught me things about Stripe integration, Supabase architecture, AI prompt engineering, and SaaS metrics that I now bring to every consulting engagement. That knowledge didn't expire when the project finished - it became a permanent upgrade to my consulting capabilities.

But I'm not a developer

I hear this objection constantly from consultants: "I can't build a product because I'm not technical."

Here's what's changed: AI-assisted development has dramatically lowered the barrier. You don't need to be a senior software engineer to build a useful product. You need to understand the problem you're solving, make clear decisions about scope, and be willing to learn.

Tools like Claude, Cursor, and modern deployment platforms (Vercel, Supabase, Stripe) have made it possible for someone with intermediate technical skills to build production-quality software. Not toy projects - real, revenue-generating products.

That said, you do need some technical foundation. If you're a non-technical consultant, I'd recommend:

1. Learn the basics. HTML, CSS, JavaScript. Not to expert level - just enough to understand what you're building.
2. Pick a no-code or low-code starting point. Tools like Webflow, Bubble, or even a well-configured Notion + Zapier setup can validate your idea before you invest in custom code.
3. Start embarrassingly small. Your first product doesn't need to be a full SaaS platform. It could be a template, a spreadsheet tool, a paid newsletter, a digital course. Something that packages your expertise into a format that scales.

The mental shift

The hardest part of building a product as a consultant isn't the technical work. It's the mental shift.

Consultants are trained to solve bespoke problems. Every client engagement is unique. Every recommendation is tailored. The idea of building something standardised feels wrong - like you're dumbing down your expertise.

But here's the thing: the problems your clients face are less unique than you think. If you've had the same conversation with five different clients about the same challenge, that's a product waiting to happen. Your expertise isn't diminished by packaging it - it's amplified.

Scorafy exists because I had the same conversation dozens of times with coaches and educators who were all struggling with the same manual reporting problem. The solution didn't need to be bespoke for each of them. It needed to be good enough for all of them, with the flexibility to adapt to their specific assessment frameworks.

Practical steps to start

If you're a consultant thinking about building a product, here's how I'd approach it:

1. List the problems you solve repeatedly. Look for patterns across your client engagements. What do you keep doing manually that could be systematised?

1. Pick the smallest viable version. Don't build a platform. Build a tool that solves one specific problem for one specific type of client.

1. Set a time limit. Give yourself four to six weeks. If you can't ship something in that window, your scope is too big.

1. Use your consulting clients as beta testers. You already have relationships with people who have the problem you're solving. Ask them to try your product and give honest feedback.

1. Don't quit consulting to build. Run both in parallel. The product funds its own growth while consulting pays the bills. Over time, the ratio can shift.

The bottom line

I'm not suggesting every consultant should become a full-time product builder. Consulting is a great business model with real advantages - flexibility, variety, high per-hour value.

But a product alongside your consulting practice creates something that neither can achieve alone: recurring revenue, compounding credibility, and a business that works even when you don't.

Building Scorafy was one of the best business decisions I've made. Not because of the revenue it's generated so far - it's early days. But because of the doors it's opened, the skills it's sharpened, and the ceiling it's removed from my consulting practice.

If you're a consultant sitting on an idea, build it. Start small, ship fast, and iterate. The worst case is you learn a lot. The best case is you transform your business.