Concierge MVP for Consulting SaaS: Validate First

A concierge MVP for consulting SaaS is a structured manual service that replicates the output your software would eventually produce, run with real clients at a real price, before a line of product code is written. It is the most direct way to validate a consulting methodology before building software, because it forces the one question that a waiting list, a survey, or a letter of intent cannot answer: will someone actually pay, repeatedly, for this output rather than for you personally?

The failure mode Ferrous Labs sees most often in expert-led businesses is not technical. It is a founder who has spent eighteen months building a platform, only to discover that their clients were buying access to their judgement and trusted them to deliver it however they liked. The software, however elegant, sits between the client and the expert in a way the client never wanted. Nobody said this during the discovery interviews, because nobody asks "would you prefer I just email you a PDF?" during a product vision workshop.

The concierge approach is the antidote. It is not a prototype, a demo environment, or a pilot with reduced fees. It is a deliberate business operation: you define the service, you set a price that reflects the value of the output rather than the cost of your time, and you sell it to people who do not already owe you a favour. If they pay, you have demand signal. If they pay again, you have retention signal. If they refer someone, you have growth signal. These are the only three signals that matter when you are deciding whether to spend material money on product development.

Why does interest not equal willingness to pay?

A recent MIT Technology Review piece on autonomous industrial AI made an observation that applies equally well here: organisations consistently overestimate their readiness to hand over a workflow to a system they cannot inspect. The same dynamic plays out in software validation. A prospective client who says "yes, absolutely, we'd use that" is imagining a frictionless future version of the tool. They are not imagining the onboarding call, the data export, the change request, or the invoice approval. Willingness to pay, measured by an actual transaction, collapses all of that imagination into a single honest signal.

This is why pre-selling a SaaS product to existing clients, while tempting, is a weaker test than it looks. Existing clients carry goodwill debt. They want to support you. They may pay for a concierge run simply because they like working with you, which tells you something useful about loyalty but almost nothing about whether a stranger would buy a subscription to the same output. If you can, run at least two or three concierge clients who found you through a channel other than a prior relationship.

What does a properly structured concierge MVP look like?

The structure matters more than the medium. A concierge MVP is not just doing your normal consulting work and calling it validation. It requires four things to be held constant across every client run.

First, a defined input specification: what information does the client provide, in what format, by when? If you accept whatever they send and work around it, you are not testing a product, you are doing bespoke work. Second, a defined output: a report, a score, a set of recommendations, a dashboard printed to PDF. The output must be the same type of thing every time, even if the content varies. Third, a fixed delivery window: a product has a service level, and your concierge must too. Fourth, a price that is not negotiated. Price negotiation is a signal in itself, but if every client pays a different amount you cannot compare willingness to pay across the cohort.

The operational overhead of holding these four things constant is exactly the point. You will discover where the method breaks down under standardisation. You will find the step that takes three times as long as you expected, or the input that clients consistently provide in the wrong format, or the output section that nobody reads. These are your product requirements, written in the language of real friction rather than hypothetical user stories.

How many concierge runs do you need before making a decision?

There is no universal number, but a useful minimum is enough runs to cover the cost of one engineering sprint with revenue, with at least two clients who renewed or reordered without being chased. That threshold is deliberately conservative. It is not proof of a scalable business. It is proof that the method produces output someone values enough to pay for twice, which is sufficient justification to move into scoped product development rather than open-ended building.

A specialist consultancy in a regulated sector might, for example, run its concierge as a fixed-price assessment delivered within ten working days. If five clients complete the process at the stated price and three return for a second assessment six months later, that is a reasonable basis for commissioning a software tool that automates the production of that assessment. It is not a basis for building a full platform with user management, API integrations, and a marketplace. Scope follows signal; it does not precede it.

The concierge phase also surfaces the question of whether the thing you are selling is genuinely the methodology or genuinely the analyst. Some expert-led businesses discover, during this process, that clients are paying for the concierge because they know who is running it, and that the output itself is a secondary concern. That is not a failure; it is important information. It means the software opportunity may be an internal efficiency tool rather than a client-facing product, which is a completely different business case with different economics.

What comes next once you have genuine signal?

If your concierge runs have produced repeatable paid demand, the next question is how to make the delivery cheaper without degrading the output. That is when software enters the conversation, not before. At that point, the product specification practically writes itself from the concierge operating procedure, and the pricing model is already tested in the market. Our SaaS Product Build partnership is designed for exactly this moment: your method is proven, the commercial case is real, and what you need is an engineering partner who co-builds the software and shares the upside rather than charging you day rates to translate your PowerPoint into a backlog. If you have been running a manual service and wondering when the right moment to productise it is, this is it.