Test Consulting Methodology SaaS Before Building It

To test consulting methodology SaaS viability before building, deliver the service manually to paying clients first and let their behaviour tell you what to automate. If you run a consultancy with a repeatable methodology, you already have the hard part: a method that solves a real problem for real clients. The question is whether that method can be systematised and sold as software, and you can answer it without writing a line of product code.

Can I build a SaaS product without a technical co-founder?

Yes, but the question worth asking first is whether you should build at all. Most founders who come to us stuck on this decision have conflated two separate risks: the risk that the product idea is wrong, and the risk that they cannot execute the build. They spend enormous energy worrying about the second before they have resolved the first. A technical co-founder, or a build partner, solves the execution risk. It does nothing for the idea risk. If you automate the wrong thing, you have simply automated a mistake.

The concierge MVP is the cleanest instrument for separating those two risks. The term has been around since the early lean-startup years, but it travels particularly well for consultancies because you are not pretending to have a product. You genuinely do have a service. You charge for it, you deliver it, and you pay close attention to which parts of the delivery are painful, slow, or dependent on one senior person's judgement. Those are the automation candidates. The parts clients never ask about, or that vary wildly from engagement to engagement, are not.

What does a concierge MVP actually look like for an expert-led business?

A specialist consultancy might take its standard assessment framework, strip out the client-facing narrative, and sell it as a structured diagnostic with a fixed deliverable and a fixed price. No software, no portal, no dashboard. The output might be a formatted report generated from a spreadsheet that a junior analyst populates while a senior specialist reviews the inputs. Clients pay. They get value. You learn which questions they always ask twice, which sections of the report they forward to their board, and which recommendations they ignore. That is your product roadmap, written by real users spending real money, before you have spent a penny on development.

The MIT Technology Review piece on AI agents is a useful reminder of something adjacent here: even the most technically sophisticated organisations discover, sometimes painfully, that automating a process before you fully understand its failure modes creates new and unexpected failure modes. The lesson for consultancy founders is not that automation is dangerous, but that understanding the human process in depth is a precondition for automating it well. Your concierge phase is that understanding.

The signal you are looking for is not just whether clients pay. It is whether they come back, whether they refer others, and whether they ask for things the current manual process cannot easily give them. That last category is your feature list. If five clients in a row ask whether they can see their results updated monthly rather than annually, you have identified a recurring-revenue product. If nobody asks anything like that, the consultancy engagement may be excellent but the SaaS thesis probably is not.

How many concierge engagements do you need before the signal is clear?

There is no universal number, but the pattern we see most often is that three to five paying engagements at a consistent price point, with at least two clients returning or actively asking what comes next, is enough to justify a serious product conversation. Below that, you are still learning what the service is. Above it, you risk over-investing in a manual process that will need to be substantially redesigned once you build software around it.

Price matters more than most founders expect at this stage. If you can only get clients to pay for the concierge service when you significantly discount it, that is information. It might mean the market exists but at a lower price point than your SaaS unit economics can support. It might mean you are not yet communicating the value clearly. Either way, you want to know before you build. A product that cannot be sold at a margin that sustains ongoing development is a trap, and the concierge phase is your cheapest opportunity to test whether you are walking into one.

One thing the concierge phase cannot tell you is whether the software version of your method will feel as trustworthy to clients as the human version. Expert-led businesses often underestimate how much of their perceived value rests on the relationship and on the visible application of senior judgement. That does not mean you cannot productise, but it usually means the software needs to make the expert's role more visible, not less. The product interface should reinforce that a rigorous method is running underneath it, rather than making the process feel like a black box. We have seen this pattern in our work with AskPhi, where surfacing the reasoning behind outputs was as important as the outputs themselves.

What should you actually automate first?

Start with the steps that are purely mechanical: data ingestion, formatting, cross-referencing inputs against a fixed framework, generating a structured output from a template. These are the steps where a junior person is doing work that a script could do faster and without error. Automating them does not change what the product is. It changes how much of a senior specialist's time is consumed in delivery, which directly affects your margin and your ability to scale.

The harder question is where the genuine expert judgement sits, and whether any of it can be encoded. In some methodologies it can, at least partially. In others, the judgement is sufficiently contextual that what the software should do is support the expert rather than replace them. That distinction shapes the entire product architecture, and you will only understand it clearly after you have delivered the service manually enough times to watch where the thinking actually happens.

If your concierge engagements reveal that the methodology is genuinely codifiable, and that clients value the output independent of who delivers it, you have a strong SaaS thesis. The next step is turning that thesis into a product built to last, which means architecture decisions, data model decisions, and commercial decisions about pricing, packaging and go-to-market. That is where a build partner earns their place. Our SaaS Product Build partnership is designed for exactly this moment: you bring a validated method and a paying client base, we co-build the software and share the upside. It is not a development agency relationship, it is a co-founder relationship without the equity negotiation happening before the idea is proven.