Productise Consulting Services: Map Costs Before You Build

There is a pattern we see often enough that it deserves naming. An expert business builds something genuinely valuable: a methodology, a diagnostic framework, a delivery process refined over years of practice. Someone, usually after a strong client result, suggests turning it into software. Within a few months there is a Figma mockup, a product roadmap, and a developer quote. What there almost never is, at that stage, is a worked model of whether the economics make any sense.

That gap, between “this would make a good product” and “this can sustain SaaS unit economics,” is where most attempts to productise consulting services quietly come apart.

What does your methodology actually cost to deliver?

Consulting economics are straightforward at their core. You charge a day rate or a project fee. Your cost of goods sold is primarily expert time, and you price to cover that plus a margin. The relationship between effort and revenue is more or less linear, which is both the constraint and the stability of the model.

SaaS economics work on a different logic entirely. The target gross margin for a software business is typically somewhere above 70 per cent, because you need that headroom to cover sales, marketing, and infrastructure and still return a profit. That means your cost to serve each additional customer must be very small relative to what you charge them. The promise of software is that it is reproducible at near-zero marginal cost. The problem is that your methodology probably is not.

When you attempt to productise consulting services, what you are really asking is: how much of my expert judgment can be replaced by code, and at what cost to build and maintain that code? The honest answer is almost always “less than we thought, and more expensive than we quoted.”

Take a methodology that involves a structured diagnostic phase, a synthesis step, and a set of tailored recommendations. The diagnostic might be automatable, at least in part. The synthesis almost certainly requires a mixture of rules, heuristics, and genuine situational reasoning. The recommendations will need calibrating to the client’s specific context. If a human expert still needs to review every output before it leaves the building, your cost to serve has not dropped by very much. What you have built is not SaaS, it is tech-enabled services, and the two have very different margin profiles and investor expectations.

None of that means the product idea is wrong. It means you need to know what you are building before you build it.

How do you actually map the costs before committing to development?

The exercise we push clients through before any line of code is written is to enumerate every step in the methodology and ask three questions about each one. Can this step be fully automated with current technology? If only partly, how much expert time remains per client engagement, and what does that cost at realistic utilisation rates? At what customer volume does that residual human cost prevent you reaching your target gross margin?

That last question is the one people skip. A small amount of expert review per customer sounds manageable when you have twenty clients. At two thousand clients it becomes your largest cost line, and it scales linearly while your software infrastructure scales near-logarithmically. The gap between those two curves is where the business case either holds up or falls apart.

There is currently a great deal of optimism about what AI can take on in this kind of reasoning work. MIT Technology Review recently covered a startup claiming to have broken through a key bottleneck in LLM capability. That kind of advance matters, but it does not dissolve the fundamental mapping problem. Even if AI reasoning improves substantially, the cost of running sophisticated inference at scale is not zero, and encoding your specific methodology, as opposed to general-purpose reasoning, requires your data, your calibrations, and usually your ongoing involvement to keep outputs accurate. Better models make some steps cheaper to automate. They do not make your methodology free to encode.

This brings us to the hidden cost almost every pre-build business case omits entirely: maintenance. Your methodology is not static. You refine it with every engagement. In a consulting model, that refinement flows naturally into how your people work. In a software product, it has to be deliberately re-encoded, tested, and released. The initial build is a one-off cost. The maintenance is a perpetual tax, and it compounds as your thinking evolves. Treat it as a rounding error in your business case and it will eventually become your biggest problem.

What does a viable productisation case actually look like?

A productisation idea tends to be worth pursuing when three things are true together. The core steps of the methodology are genuinely systematisable, not just in principle but in the actual data structures and rules needed to implement them. The residual human cost per customer, modelled at realistic scale, still allows a gross margin that supports the business you want to build. And the addressable market is large enough that achieving the required scale is plausible rather than merely conceivable.

When we worked with Growth Gorilla, one of the early disciplines was distinguishing the process steps that created genuine leverage when systematised from the human judgment that was, effectively, the product itself. That distinction shaped everything about what we built together and, just as importantly, what we did not build.

The mapping exercise is not glamorous. It does not involve a prototype or a roadmap. It involves a spreadsheet, realistic assumptions about your own time, and the willingness to arrive at a number that might tell you the idea is not ready yet. That is valuable information. Building twelve months of software to discover the same thing is expensive information.

If the mapping does validate the idea, you are in a genuinely strong position: a methodology that works at service level, a cost model that supports SaaS margins, and a clear understanding of what actually needs to be built. That is exactly where our SaaS Product Build partnership begins. We co-build the software and share in the upside, which means we have every reason to be straight with you about the economics well before a line of code is written.