You May Already Be Running a Concierge MVP

A concierge MVP means delivering the outcome your eventual product will automate, but delivering it manually, with human expertise doing the work software will one day do. The specialist consultancy most ready to build a SaaS product is often the one that has never thought of itself as a software business at all, because it has been running a concierge MVP for years and calling it the service.

That reframing matters more than it sounds, because of what it changes about the timetable. Treated as a startup technique, the concierge phase is a hurdle to clear: run it, learn what you need, move on to the real work of building. Treated accurately, it is the most valuable asset in the business and the one part a competitor cannot acquire quickly. The months you spend delivering by hand are not the delay before the product. They are what makes the product difficult to copy.

In this blog, Elliott Prince, Managing Director at Ferrous Labs, explains why an established consultancy is probably already running this experiment, what the slow period actually produces, and how to tell which parts of your service are worth turning into software.

Are you already running one without realising it?

If your business delivers a repeatable process for clients, charges for outcomes rather than hours, and applies an internal method to produce those outcomes, there is a reasonable chance you are running a concierge MVP and filing it under normal trading.

Consider what that looks like in practice. A growth advisory analysing a client's acquisition funnel and returning a prioritised action plan. A due diligence practice synthesising data from several sources into an investment memo. A regulatory consultancy reviewing documentation and returning a structured gap analysis. In each case there is a method, applied consistently, producing an output somebody pays for. The method is the proto-product, and the clients paying for it are validating demand before any software exists.

The shift worth making is to stop seeing the service as competition for a potential product. The clients who keep coming back are not buying your time as such; they are buying the outcome your method reliably produces, which is precisely what a subscription sells. There are signals for this in how clients talk to you, and they are easy to miss because they sound like scope creep. When somebody asks whether they can access the process directly, whether there is a portal, whether they could run their own queries between engagements, they are describing a product they would pay for. They are asking for the method, packaged separately from the person who delivers it.

The inverse signal is worth as much. If delivery is consuming more capacity than you can comfortably scale, and the constraint is the hours required rather than the quality of the thinking, the bottleneck is operational rather than intellectual. Software tends to be a better answer to an operational bottleneck than hiring is.

The slow part is the point

Here is the argument that does not get made often enough, and it is the reason not to rush this phase even when you could.

Running your method as a service generates something no competitor can replicate on a schedule: the actual patterns of how your specific client type deals with your specific kind of output. Not market research and not synthetic test data, but the granular record of what clients flag as wrong, what they ask to have reformatted, which sections they read first, what they print and what they forward. That accumulated understanding becomes the specification for the software, and somebody starting two years later cannot buy their way to it.

The contrast is stark once you see it. A business that builds without this foundation is making educated guesses about interface, edge cases and how much the output needs to explain itself before a professional will rely on it. A business that has spent three months running the approach with real clients is not guessing about any of that. It knows. And that knowledge gap does not close with funding, because what produced it was time and proximity to a particular market.

In specialist professional markets the effect compounds further, because those markets are relationally dense. Clients know each other, referrals travel quickly, and reputation accumulates. If your early clients become visible advocates for the tool partly because they helped shape it, the advantage is social as well as technical, and social advantages are the slowest of all to copy.

One honest limit on all this. It works because you already have clients willing to engage with something half-built and tell you the truth about it. If you are entering a market where you have no relationships, validation looks quite different and this post is not describing your situation. For an established specialist business, though, the existing client base is the most valuable asset in the whole exercise, and it is rarely used deliberately enough.

Which parts of your service are worth productising?

Not everything a consultancy does is a sensible candidate. The parts worth examining share a few characteristics: the work is broadly repeatable between clients, it involves processing or structuring information rather than exercising creative judgement, and it consumes more time than the value it produces really justifies. Those are the places where software can absorb the volume so that your expertise concentrates on the decisions that genuinely need it.

The narrow question to hold throughout is not whether clients like the output. They will, particularly if they like you. It is whether a subset of them would pay separately for access to the capability rather than paying for your time. If even two or three would, you have something worth building. If the answer is that they value it but are not sure they would pay for it directly, you have learned something important and considerably cheaper than a development budget.

In our experience six to eight weeks of deliberate delivery answers most of this, provided you treat it as an experiment rather than as business as usual. The questions are narrow enough to answer quickly: is the output genuinely useful or merely impressive, will clients adjust their own processes to accommodate it, and would they buy it without you attached.

Jason was delivering it by hand for years

Jason Nguyen spent eleven years as a professional poker player, making decisions on incomplete information and reading behaviour under pressure, then formalised that instinct through behavioural science and built Bloom Story, his behavioural marketing consultancy. The thesis was sharp: most companies profile an audience by demographics, when what matters is understanding why people buy, leave, or never considered you at all.

For years that thesis was delivered as consultancy, client by client. Which is to say the concierge phase had already run, thoroughly, before any of the software questions came up. When Jason did build a prototype with Claude Code it proved the concept and had every problem an early build has: brittle at the edges, no multi-user support or proper data layer, no structure anybody could actually purchase, and not something a paying customer could use without him. We took three months to turn that into a production platform with four core workflows, and it went live with paying clients.

The part I find most instructive is what AskPhi looks like now, because it answers the question this whole approach usually leaves hanging.

So when do you stop doing it by hand?

Most people ask that question far too early, and the usual answer is to keep going until you have seen the full range of what clients do with the work rather than the range you expected. A product built before you understand that range is a product built for your first client rather than your tenth.

But AskPhi suggests a better answer, which is that you may not stop at all. It runs two revenue streams: a done-for-you sprint alongside the self-serve platform. The concierge service did not end when the software shipped. It became a tier, and a premium one, for clients who want the outcome without operating anything themselves.

That is worth sitting with if you have been treating this as a sequence with an exit. The service and the product are not competing for the same customer, and a consultancy that assumes it must choose usually delays the product for years on a false premise. The software serves the clients who want to run it themselves. You keep serving the ones who would rather you did it, at a rate that reflects the fact that you built the thing.

Start by renaming what you already do

The practical first move costs nothing, which is unusual for anything worth doing. Go back over your last two years and mark which engagements were substantially the same job under different client names. Then look at that list and stop calling it delivery. It is a product trial that clients have been funding, and the only thing missing is that nobody wrote down what it was teaching you.

Start writing it down now, deliberately, in the places the specification will eventually come from: which parts of the output clients query, what they always ask to have changed, where the work takes longest relative to what it is worth. In our experience three months of that produces a better requirements document than any workshop, and unlike a workshop it pays for itself while it runs.

What you end up with is more useful than a validated idea. You have clients already invested in the outcome, requirements drawn from real use rather than assumption, and pricing anchored to what people have demonstrably paid rather than to a competitor's website. You know what the market will pay because it has been paying it, repeatedly, for the thing the software will do. Most businesses trying to build a product would trade a great deal for that position, and you are already in it.