SaaS unit economics for consultancies - what your methodology actually costs to deliver

SaaS unit economics is the relationship between what it costs you to serve one more customer and what that customer pays: get it right and growth funds itself, get it wrong and every new customer makes the problem larger. For a consultancy turning a methodology into software, it is the calculation that decides whether you have a product or an expensive way of doing the same work.

There is a pattern here we see often enough that it deserves naming. An expert business builds something genuinely valuable, usually a methodology or a diagnostic framework refined over years. After a strong client result somebody suggests turning it into software. Within a few months there is a mockup, a roadmap and a developer quote. What there almost never is, at that stage, is a worked model of whether the economics hold.

In this blog, Elliott Prince, Managing Director at Ferrous Labs, sets out what a methodology actually costs to deliver once it is software, what margin you are really aiming at, and how to find out which side of the line you are on before anybody writes code.

What does your methodology actually cost to deliver?

Consulting economics are simple at their core. You charge a day rate or a project fee, your cost of goods sold is mostly expert time, and you price to cover that plus a margin. Effort and revenue move together, which is the constraint and also the stability of the model.

Software economics work on different logic. The promise is that the thing is reproducible at near-zero marginal cost, so the cost of serving one more customer is small relative to what they pay, and the gap funds everything else. The difficulty is that your methodology is probably not reproducible at near-zero marginal cost, and the question worth asking is not whether it could become software but how much of your expert judgement code can carry, and what building and maintaining that code costs.

Take a methodology with a structured diagnostic phase, a synthesis step and a set of tailored recommendations. The diagnostic is often partly automatable. The synthesis usually needs a mixture of rules, heuristics and genuine situational reasoning. The recommendations need calibrating to a particular client's circumstances. If a human expert still reviews every output before it leaves the building, your cost to serve has barely moved. What you have built is tech-enabled services rather than software, and the two carry very different margin profiles and very different expectations from anybody funding them.

That is not an argument against the idea. It is an argument for knowing which one you are building before you commit to it.

The number you are aiming at is higher than you think

Most people assume the bar is somewhere around 70 per cent gross margin. The published benchmarks put it higher. The 2026 SaaS and AI Performance Benchmarks, produced by Aleph and Benchmarkit across 342 B2B SaaS and AI-native companies using full-year 2025 figures, put the median software gross margin at 80% and note it has held between 79% and 81% for four consecutive years.

The more useful figure in that report is the second one. Median gross margin on total revenue is 76%, four points below the software-only number, and the gap is services revenue pulling the blended figure down. That difference is precisely the distinction in the section above, expressed as a number: the more of your delivery that still requires people, the further your blended margin sits from the software benchmark, and the further it sits the less your business behaves like the thing you set out to build.

There is a third figure worth holding onto, because it is the one that catches AI products specifically. Usage-based models post the lowest median gross margin in that sample at 62%, which the report attributes to higher infrastructure and compute costs. Inference at scale is not free, and it lands in exactly the line of the accounts you were hoping software would improve.

How to map the cost before you commit

The exercise we run before any code is written is to enumerate every step in the methodology and ask three questions of each one. Can this step be fully automated with technology that exists now? If only partly, how much expert time remains per engagement, and what does that cost at realistic utilisation? And at what customer volume does that residual human cost stop you reaching the margin you need?

The third question is the one people skip, and it is the one that decides the business. A little expert review per customer sounds manageable at twenty customers. At two thousand it is your largest cost line, and it grows in a straight line while your infrastructure costs grow far more slowly. The distance between those two curves is where the case either holds or collapses, and you can model it on a spreadsheet in an afternoon.

Then there is the cost almost every pre-build case omits entirely, which is maintenance. Your methodology is not static; you refine it with every engagement. In a consultancy that refinement flows naturally into how people work, and costs nothing visible. In a software product it has to be deliberately re-encoded, tested and released. The build is a one-off cost. The maintenance is a standing charge that grows as your thinking does, and treating it as a rounding error is how it becomes the largest number on the page three years later.

Better models do not make your methodology free to encode

The obvious objection to all of this is that model capability keeps improving, so the share of the work code can carry will keep rising and the residual human cost will look after itself. Some of that is true, and it does move the line. It does not dissolve the problem, for a reason worth being precise about.

A better general-purpose model is better at general-purpose reasoning. Your methodology is not general-purpose, and the evidence on that gap is quite stark. In a benchmark published in April 2026, a small open model fine-tuned on a specific legal domain, updating just 0.3% of its parameters, reached 87.6% accuracy on a five-way classification task, some 28 points ahead of GPT-4o mini. On one category the commercial model scored an F1 of 0.00 against the fine-tuned model's 0.91. That is a simple task in a well-documented field, and the general model did not merely underperform on it, it collapsed.

The lesson transfers directly. Encoding what you specifically do, as opposed to what a model can reason about generally, needs your data, your calibrations and usually your continued involvement to keep the outputs right. Better models make some steps cheaper to automate. They do not make your particular methodology free to encode, and the 62% margin on usage-based products is the reminder that even the steps they do take are being metered.

What a viable case actually looks like

A productisation idea is worth pursuing when three things are true together. The core steps are genuinely systematisable, not 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 leaves the margin the business needs. And the addressable market is large enough that reaching that scale is plausible rather than merely conceivable. When all three hold, the design question shifts to how you productise consulting services while keeping a person in the loop wherever the judgement lives.

When we worked with Growth Gorilla, one of the early disciplines was separating the process steps that gained something real when systematised from the human judgement that was, in effect, the product itself. That distinction shaped what we built and, just as importantly, what we agreed not to build. It is a less enjoyable conversation than a roadmap and considerably more useful.

An afternoon with a spreadsheet, or twelve months finding out

None of this is glamorous work. There is no prototype at the end of it and nothing to show anybody. It is a spreadsheet, honest assumptions about your own time, and a willingness to reach a number that might tell you the idea is not ready. That is an uncomfortable afternoon, which is why it gets deferred until after the build, when the same answer costs twelve months and a development budget instead.

So do the mapping first, and do it on the workflow you would actually productise rather than on the business in general. Enumerate the steps, mark which ones need a person, cost that person properly, and find the customer volume where the residual cost breaks your margin. If that number is comfortably beyond any market you could realistically reach, you have your answer cheaply.

And if it holds, you are in a genuinely strong position: a methodology that already works at service level, a cost model that supports the margin you need, and a clear view of what has to be built and what does not. Most businesses that set out to build a product would trade a great deal to start from there, and the only way to know whether you do is to work it out.