Productisation: Turning a Service Into Software You Sell

Productisation is the process of turning a service you deliver by hand into something that can be sold without you in the room: first a fixed-scope, fixed-price offer, and then, if the economics hold, software your customers pay for directly. For a UK service business it is the difference between selling hours and selling an outcome, and it is the only route to revenue that does not grow in step with headcount.

Here is a blunt question to start with. If you took a month off, which of your clients would notice? For most specialist businesses the honest answer is all of them, because the thing they are paying for is you: your judgement, your method, your name on the report. That is a fine way to run a practice and a hard way to build an asset. Every pound of revenue needs a senior hour behind it, the diary is the growth ceiling, and the day you stop is the day the income does.

The usual response is to hire, which raises the ceiling a little and raises the cost base a lot. The less usual response is to look hard at what you actually do for people and notice that a surprising amount of it happens the same way every time. That repetition is a product in disguise, and finding it is where productisation begins.

In this guide, Elliott Prince, Managing Director at Ferrous Labs, sets out what productisation actually involves, which parts of a service can be productised and which genuinely cannot, what it costs (including the cost that never appears on a quote), and the order to do it in so you are never betting the company on a build.

Three rungs, and most businesses are standing on the first

It helps to think of productisation as a ladder with three rungs rather than a single leap. On the first rung is the service as you deliver it today: scoped per client, priced per day or per project, dependent on whoever is best at it. On the second is a productised service, which means the same work packaged into a defined scope at a fixed price with as little customisation as you can get away with. The method is still delivered by people, but the selling, the scoping and most of the arguing about scope have gone. On the third rung is software: your method encoded into a product that runs without you, sold on a subscription, owned by you.

Plenty of businesses are perfectly well served by stopping on the second rung, and it is worth saying so, because the industry that sells "build a SaaS" rarely does. A productised service alone can double margins, because fixed scope removes the unpaid discovery and the scope creep that eat consultancy profit. The third rung is for when the second one proves two things: that customers will pay for the outcome rather than the hours, and that the outcome can be produced by a process rather than a person. When both are true, the step from rung two to rung three is turning your consultancy into a software product, and it follows a recognisable sequence.

You will also hear the phrase "service as software" used for the top rung, meaning a product where AI does the work and the customer pays for the finished result rather than for a tool to use. It is a useful label for where this ends up, but the path to it is exactly the same. You still need the repeatable core, the proof that people will pay, and the smallest build that removes you from delivery.

Which parts of your work are actually productisable?

This is the question everything else depends on, and it is the one most businesses skip. The instinct is to productise the whole service, which produces either a bloated build that tries to encode judgement it cannot capture, or a thin one that automates the easy ten per cent and leaves the expensive work exactly where it was.

The honest answer is that nearly every expert practice contains two kinds of work. Some steps run the same way for every client: the intake, the data gathering, the standard analysis, the first draft of the recommendation, the report formatting. Other steps genuinely need an expert in the room, because the client's situation is unusual or the stakes are high enough that someone has to own the call. Productisation lives in the first kind. The second kind is what you keep selling by the day, at a higher rate, because the product has freed you to.

The way to tell them apart is to draw a repeatability map: a step-by-step account of how you deliver an engagement, with each step marked as routine or expert. It sounds obvious. In practice the routine parts are the hardest to see, because you have done them so many times that they no longer feel like steps at all. Clients, on the other hand, see them clearly, which is why "could you just send me the template" is one of the better signs a step is productisable.

What does productisation cost?

Let's be honest about the numbers, because most of what is written on this subject is either vague or selling something. In our own work, scoping a custom AI product runs from £5,000 to £20,000, and a production system runs from £80,000 upwards. Where a specific build lands inside those ranges depends almost entirely on how much of the method the map has shown to be routine; a product that automates a well-defined process costs a fraction of one that has to approximate judgement.

Those are the figures on the quote. The larger cost is the one that never appears on any quote, which is your own attention. A founder billing £1,000 a day across 180 days a year who spends 30 per cent of that attention on productisation for eighteen months has forgone around £81,000 in billing, before a line of code has shipped. Nobody invoices you for that, so it feels free, and it is the main reason productisation projects stall halfway: the cash cost was budgeted and the attention cost was not. Our piece on the hidden cost of productising your consultancy walks through the arithmetic, and the companion on unit economics for a consultancy SaaS build shows how to work out, before any code exists, which steps are worth automating at the price your market will bear.

Critically, cheaper development has not changed this. AI-assisted coding has cut the cost of building the first version, and that is real; what it has not cut is the cost of deciding what to build, testing whether anyone wants it, and running it once it exists. Those are the parts that take your time, and they are the parts that decide whether the product makes money.

Sell it before you build it

Which leads us to the order of operations, because the single most expensive mistake in productisation is building first and asking second. The cheapest way to find out whether your method is worth productising is to price it like a product and offer it to the clients you already have. If they will pay a subscription for a defined scope of your work, you have demand; if they will not, you have saved yourself a build and a year. The approach is set out in how to validate a SaaS idea from an existing service, and it works because willingness to pay tells you something no interview can.

There is a quieter version of this test that many businesses are already running without noticing. If you deliver the same outcome for client after client by hand, you are operating what product people call a concierge MVP: the service is the prototype, the clients are the test users, and the only thing missing is the decision to treat it that way. That reframing matters, because it means the question is not "should we build a product?" but "which of the things we already sell should stop needing us?"

What it looks like when it works

Jason Nguyen spent eleven years as a professional poker player before formalising what he had learned about reading people into Bloom Story, a behavioural marketing consultancy. His thesis was that demographics tell you who someone is and behavioural intelligence tells you what they will do next, and he had delivered it for clients by hand for years. He had also built a working prototype with Claude Code that automated the core of it. The prototype proved the idea and had every weakness a vibe-coded build has: no production architecture, brittle at the edges, no multi-user support.

What turned it into AskPhi was the sequence above, run deliberately. First, understanding the behavioural logic underneath the prototype rather than just the code, and from that identifying the four workflows that had to be real and sellable. Then a minimum viable version tested with Jason's existing consulting clients, with real data, before anything was scaled. Then a production build, and a two-mode product: a Done-For-You sprint for clients who want the outcome delivered, and a self-serve platform for those who want the tool. AskPhi had paying clients, including Run It Once, Teleya and Slippery Saints, within three months of the build starting. The consultancy did not disappear; it became the premium tier of a product.

You do not need a technical co-founder, but you do need a partner who stays

The last objection is usually the practical one. A service business does not have a product team, and the traditional route to software, hiring one or giving a technical co-founder a large slice of equity to lead the build from inside, is exactly the bet most founders are right to be wary of. The good news is that it is no longer the only route. A specialist studio can act as the technical side of the business under a structure that fits how you want to fund it: pay for the build outright and own the product, or reduce the upfront investment through a revenue or equity partnership from the production stage onwards. Our guide to building a SaaS product without a technical co-founder compares the options honestly, including the ones where we are not the right answer.

Whichever route you take, look for the same four things. A short definition stage that fixes the product and the business model before anyone builds. A fast first version that proves people will pay, tested on real customers. A production build that will hold up to growth. And someone who stays to run it, because software that nobody maintains decays, and a product that has stopped improving is a liability with a login page. That is the shape of our SaaS product build, and it is the shape of every productisation we have seen succeed, including the ones we had nothing to do with.

Start by drawing the map

You may be reading this with a full diary and a quarter to close, thinking that productisation is a project for a calmer year. The trouble is that calmer years rarely arrive, and the window is not standing still. ONS figures put the share of UK businesses with ten or more employees using AI at around 12 per cent in late 2023 and around 35 per cent by June 2026. The businesses in your field that productise first will set the price for everyone who follows.

So start small, and start with paper rather than code. Draw the repeatability map for your most common engagement, mark each step routine or expert, and put a product price on the routine part. Offer it to three existing clients. What you learn from that exercise will tell you whether to stop at a productised service, go on to software, or leave things exactly as they are, and every one of those is a better place to be than guessing. The businesses that make this work are not the ones with the best idea; they are the ones who found out what their method was worth before they built anything, and then built only that.