Skip to main content
SaaS

Consulting firms: the window to productise your expertise is closing

Your clients are automating the work you bill in person-days. Productising your method as a SaaS is still possible — provided you don't spend 18 months in R&D first.

Équipe SwoftPôle stratégie produit
Réunion d'associés dans un cabinet de conseil discutant d'une stratégie de productisation

Inside consulting, HR, legal, accounting, marketing and finance firms, the conversation shifted in 2025. Partners no longer ask whether AI will hit their model — only how fast. And above all: should we try to productise what we know how to do, before our clients do it themselves?

The pattern is the same everywhere. A share of repetitive work — document synthesis, preliminary due diligence, standard-contract review, recurring reporting, first-line qualification — is being absorbed by the tools clients install themselves. The ratio of billable person-days per engagement is dropping quietly. Not violently, but durably.

The productisation bet, and why it usually fails

Turning a firm's know-how into a SaaS platform isn't a new idea. It comes back in cycles, with every technology wave. Internet, mobile, cloud, AI. Every time, a fraction of firms try. Every time, most give up after twelve to eighteen months, with the same lucid verdict: we didn't ship, we burned cash, and we distracted our best partners from the core business.

Three traps recur. First, scope drift: a firm productising its method tends to want to reproduce in software the full richness of what it delivers in engagements, instead of isolating the repetitive, codifiable layer. The result is an ambitious product, slow to ship, hard to sell. Second, the under-staffed internal team: hiring a CTO, two engineers and a PM takes six to nine months, and by the time the team ships, the market has moved. Third, the confusion between consulting and product: a firm that bills hours knows how to sell expert time; selling a £199-a-month subscription requires a different commercial culture.

What changed in 2026

Two things make productisation more accessible today than it was two years ago, and a third one makes it more urgent.

More accessible: generative-AI building blocks now let you encode business behaviour that previously demanded years of R&D. A firm that knows from experience how to qualify a case or draft a first synthesis can now transmit that logic to an AI agent in weeks — provided there is a clean piece of software to host it. Domain modelling — once outsourced to expensive external consultants — can be industrialised in code from version one.

More urgent: clients themselves are adopting ChatGPT, Claude, Mistral. What used to be a competitive edge on internal productivity — being able to handle a case in two days rather than five — becomes invisible when the client expects the same speed. The moment a client says "I'll just do this myself with ChatGPT" is the moment the commercial window closes.

Productising without breaking the firm

The operational question is rarely "can we productise?" but "how do we productise without damaging the firm during the effort?". Partners who pull this off share a few principles.

Isolate the repetitive layer, not the entire business

A firm never productises its full core practice. It productises the lower layer — the repetitive, codifiable work, low incremental value per engagement but high volume. That layer is precisely the one clients are starting to automate themselves. Productising it means taking that part of the value chain back, and freeing partners for the upper layer where human expertise stays irreplaceable.

Sell v1 to existing clients, don't chase new ones

A firm launching a SaaS has an asset nobody else does: a portfolio of clients already convinced of the consulting quality. Version one shouldn't chase new markets — it should be offered to existing clients as a complement to consulting work, often at cost in the first year. That brings fast feedback, social proof, and predictable revenue ahead of acquisition.

Cap the bet at twelve weeks, not eighteen months

A firm cannot afford a long R&D cycle. Not for lack of cash — many have it — but because partner attention is the scarcest resource. Capping version one at an eight-to-twelve-week scope forces discipline: pick the most profitable sub-problem, implement it cleanly, put it in front of a real client, learn. The rest follows or doesn't. What you avoid is the eighteen-month project that drains energy without generating revenue.

The invisible technical layer that makes the difference

On paper, a consulting-firm SaaS looks like any other B2B SaaS: interface, database, authentication, subscriptions. The difference plays out in domain modelling. A firm that productises without modelling its domain produces software that demos well but starts diverging by the third client: business rules scattered across the code, edge cases piling up, and the AI agent eventually hallucinating on situations the firm itself has handled in engagements for ten years.

Conversely, software that explicitly models the concepts of the business — the participants' roles, the states of a case, the transition rules, the invariants — becomes a substrate on which agents can be plugged that behave like a serious junior of the firm. The agent doesn't guess; it operates on a model that contains the knowledge.

What decision for 2026

Not every firm is meant to become a SaaS vendor, and some expertise doesn't productise — the kind whose value lies precisely in the relationship, the contextual judgement, the interpersonal trust. For the rest, the decision isn't binary between "productise everything" and "do nothing". It is: which fraction of our lower layer can be turned into a product within twelve months, with which partner, and with what level of human commitment.

What will no longer be available in 2027, however, is the option "let's watch and wait". The motion is already underway among the clients themselves, and waiting is paid for in margin.

Sujets abordés

  • Productisation
  • Cabinet de conseil
  • SaaS
  • Agents IA
  • Domain-Driven Design
  • Time to market
  • Multi-tenant
Tech translation

How Swoft turns this challenge into software

Côté ingénierie, productiser une méthode de cabinet exige une architecture conçue dès l'origine pour accueillir des règles métier évolutives et des agents IA opérables. Voici les capacités logicielles que nous mettons en place.

  1. 01

    Modélisation domaine-driven du savoir-faire

    Les concepts du cabinet — rôles, états, règles de transition, invariants — sont explicités dans le code. Le logiciel devient le jumeau numérique de la méthode, ce qui rend les règles inspectables et modifiables sans réécrire l'application.

  2. 02

    Agents IA ancrés dans le modèle métier

    Les agents n'opèrent pas sur des prompts bricolés mais sur le modèle de domaine. Ils savent qui est qui, ce qu'on attend, quelles règles s'appliquent, et leurs actions sont auditées par le moteur métier.

  3. 03

    Multi-tenant dès la v1

    L'architecture isole les données et les règles de chaque client cabinet final, avec des paramètres de personnalisation par tenant. Pas de refonte douloureuse au moment du dixième client signé.

  4. 04

    Cadrage scope-locked en douze semaines

    Le périmètre fonctionnel est gelé contractuellement à l'issue d'un kick-off d'une semaine. Le reste du temps est consacré à livrer, pas à arbitrer. C'est la condition pour tenir la promesse de délai.

Questions fréquentes

À retenir sur ce sujet

À partir de quelle taille un cabinet peut-il sérieusement envisager de productiser ?
L'effectif compte moins que la maturité de la méthode et la base de clients existante. Un cabinet de quinze associés avec une méthode codifiée et trente clients récurrents est mieux positionné qu'un cabinet de cent personnes sans méthode formalisée. Le seuil pratique se situe souvent vers cinq à dix millions d'euros de chiffre d'affaires, à partir duquel un investissement de cent à deux cents mille euros sur un produit ne menace pas la trésorerie.
Faut-il créer une filiale dédiée ou intégrer le SaaS dans la structure existante ?
Une filiale dédiée a deux avantages : isoler la comptabilité du produit, et préparer une éventuelle valorisation séparée. Mais elle complique la gouvernance et alourdit la fiscalité. Pour la majorité des cabinets, démarrer dans la structure existante est plus pragmatique, et la filialisation peut intervenir une fois que le produit a démontré sa traction commerciale.
Quel est le risque de cannibaliser le conseil ?
Le risque existe mais est souvent surestimé. La productisation prend en charge la couche basse de la mission — celle qui était déjà sous pression de l'IA des clients eux-mêmes. Bien menée, elle libère du temps d'associé pour la couche haute, où la marge horaire est meilleure. Le scénario inverse — ne pas productiser et voir le client se servir lui-même de ChatGPT pour la couche basse — est généralement plus coûteux.
Combien de temps avant que la v1 commence à générer du chiffre ?
Sur les configurations que nous voyons, une v1 livrée en douze semaines, déployée chez trois à cinq clients existants à prix coûtant pendant le premier semestre, commence à générer un chiffre d'affaires significatif au mois neuf à douze. L'intérêt n'est pas tant le chiffre rapide que la donnée d'usage et la preuve sociale, qui rendent la phase d'acquisition externe ensuite beaucoup plus efficace.

Continuer la lecture — SaaS

  • NIS2 for SaaS vendors: six months to pass the audit
    Salle serveur d'un éditeur SaaS avec consoles de supervision sécurité

    NIS2 for SaaS vendors: six months to pass the audit

    Applicable since October 2024, the NIS2 directive starts to bite in 2026. SaaS vendors classified as "important entities" face new technical obligations.