Productise Your Consultancy: The Hidden Cost

You've decided to productise your consultancy. You've had quotes from development studios, looked at no-code platforms, built a rough spreadsheet. You think you know what this will cost. You probably don't, because the biggest line item isn't in any quote you've received.

The number you're missing is your own day rate multiplied by every hour you spend on this instead of billing clients.

This isn't a gotcha. It's a calculation almost nobody does before they commit, and skipping it is why so many consultancy-to-product transitions stall in year two with a half-finished codebase and a founder who has quietly halved their income.

Why does development cost feel real but your time feel free?

A development invoice is concrete. Someone sends it, you pay it, it appears in your accounts. Your foregone client revenue, by contrast, is invisible. Nobody invoices you for the work you didn't take on while you were writing product specifications and sitting in sprint reviews. So when consultants budget a productisation project, they treat the software build as the cost and their own time as overhead, or worse, as free.

It isn't free. Consider a sole-trader consultancy billing at £1,000 a day across 180 days a year. If productisation consumes 30% of that attention over eighteen months, the foregone billing across that period is around £81,000. That number often exceeds the development quote, sometimes comfortably. And unlike a development invoice, it compounds: the clients you didn't take on in year one are also not referrers in year two.

There is a subtler cost too: cognitive switching. A founder who is half-consulting and half-building is rarely fully effective at either. A consultancy methodology lives primarily in the founder's head. It is tacit knowledge, contextual and judgement-heavy, full of exceptions that seem obvious until you try to encode them in software. Externalising it into a working product requires sustained, expert attention from the person who holds it. That means weeks of discovery work before a line of code is written. It means being available for questions throughout the build. And it means testing not just for bugs but for whether the software actually produces the outcomes your service produces. None of this appears in a development quote, and all of it gets squeezed into gaps when attention is divided.

How do you actually run the numbers?

The calculation is not complicated. Start with your realistic annual billing capacity: your day rate multiplied by the number of days you genuinely bill, not the number you intend to. Then estimate, honestly, what percentage of your working time the productisation project will absorb across all phases: discovery, build oversight, testing, launch, early sales. Multiply those two figures together. That is your annual opportunity cost.

Then estimate how long the project will run before the product generates enough revenue to replace what you gave up. Eighteen months is a reasonable baseline for a first SaaS product; two years is common. Multiply your annual opportunity cost by that duration and add the development cost. That total is what the project actually costs.

For many consultancies this exercise produces a number that is sobering but not prohibitive. The product still makes sense. But the founders who navigate productisation well are the ones who know the real figure before they commit, not halfway through when client revenue has dropped and the bank account is doing something unexpected.

Does cheaper AI development change the equation?

It changes one part of it. MIT Technology Review recently traced how the underlying AI infrastructure layer is taking shape, and that maturation genuinely flows through to the cost of building software. A product that might have taken twelve months to build two years ago can sometimes be built in six. That is real progress, and it matters.

But faster, cheaper development does not reduce your opportunity cost. If anything, it makes your time a larger proportion of the total. If the development bill drops by a third and your foregone billing stays constant, your own attention becomes the dominant variable in the equation by an even wider margin. This is the part of the AI productivity story that consultancies rarely hear: as build costs fall, the economics of productisation do not simply get easier. They get more founder-constrained, not less.

This is also why the partnership model for productisation deserves serious consideration. If a technical partner co-builds the software and shares the upside rather than charging a flat fee, the development cost moves from a cash outlay to a revenue share. It does not eliminate your opportunity cost, but it changes the risk profile. You are no longer writing large cheques upfront against an uncertain future revenue stream.

Run the numbers before you commit. Calculate your opportunity cost over the expected project duration. If it is less than half the total, development is the dominant risk and you should scrutinise the build estimate hard. If it is more than half, your own time is the real constraint, and you need a concrete plan for it: reducing client commitments, hiring to free yourself up, or finding a build partner who reduces the hours you need to put in.

If the economics do work out, the next step is turning that methodology into a product you can sell at scale. That is what our SaaS Product Build partnership does: we co-build the software alongside you and share the upside, which means our incentives are aligned with yours from day one rather than ending when the final invoice is paid.