Lexlane: AI made it cheap to build the wrong thing

In September 2025 I started Lexlane with two friends: an accountant, and a law student in his final year, preparing for the bar. The plan was to build practice management software for French lawyers. All of it. Clients, cases, billing, documents, deadlines — one tool instead of six.

I shipped a working product in about three months. Then I spent the rest of the year learning that shipping was never the hard part.

The cost of building collapsed. The cost of being wrong did not. When those two move in opposite directions, building fast stops being an advantage and starts being a way to be wrong faster.

Mistake one: all-in-one is a promise you renew every month

The pitch we wrote at the time still sums it up: give lawyers back time for legal reasoning, and give their clients a clear relationship with the law. On the lawyer side we were attacking four things — fragmented tools that do not talk to each other, time lost on billing and chasing unpaid invoices, prospecting that eats the week, and what is left for actual legal work. On the client side, four more — not understanding the procedure, no visibility on where the case stands, a relationship that feels one-sided, and the anxiety that comes with all of it.

Eight problems. One product. That was the plan, and writing it out like that should have been the warning.

Picking a vertical and owning the whole workflow sounds like strategy. It reads well on a landing page. In practice it means every feature you ship becomes a feature you maintain, forever, for a user base small enough that no single feature ever pays for itself.

The part I did not see coming is the paradox underneath it. The more you build, the more users ask for. An all-in-one product sets an expectation of completeness, and completeness is not a state you reach — it is a treadmill you get on. Every new customer arrives with the one thing their old software did that yours does not, and because you promised all-in-one, you have no principled way to say no.

A narrow tool can say "that is not what this does." An all-in-one tool cannot. I removed my own ability to refuse work.

Mistake two: I did not know who was buying

I had barely met a lawyer before starting a company that sold to lawyers. I had to learn what they actually do all day, what pulls them toward a piece of software, and what they are willing to pay.

That last one was the expensive lesson. In France, avocat is a protected title and a demanding profession, but it is not a synonym for money. A large share of the profession is solo practitioners and small firms running on thin margins, and software sits in a budget line that gets cut before anything else. I had confused prestige with purchasing power, and market size with addressable market.

The seats that do exist were taken a long time ago. Septeo and its Secib line, Kleos at Wolters Kluwer, LexisNexis, and a handful of others have been installed in these offices for years, often bundled with the bar associations and the accounting workflow. Switching costs in a law firm are not measured in migration effort — they are measured in the risk of losing a file. Nobody takes that risk to save fifteen euros a month on a tool that is younger than the case they are working on.

I should have made ten phone calls before writing a line of code. I made them after.

What AI actually changed, and what it did not

Three months, effectively alone on the engineering, for a product with real multi-tenant data, permissions, document handling and billing. That would not have been possible for me two years earlier. Working with Claude, the distance between "I understand the problem" and "there is a working implementation in front of me" got short enough that the implementation stopped being the thing I thought about.

This is genuinely new and I do not want to undersell it. But it moves the bottleneck rather than removing it. When building is cheap, the constraint that used to protect you disappears. Before, scope was disciplined by pain: you could not build the all-in-one, so you did not. Now you can. So you do. And you end up with a large, correct, well-built product aimed at a market that cannot pay for it.

The skill that matters now is not shipping. It is choosing.

The part I would build again

One piece of Lexlane I am still proud of: the AI is not a chatbot sitting next to the app. It writes into the database.

Most "AI in your SaaS" is a panel on the right that answers questions about data it can only read. I wanted the opposite. A lawyer types a sentence — a client's name, a hearing date, a note about a case — and it lands in the right record, in the right field, without anyone opening a form.

The model is the easy part of that. The hard parts are the two on either side of it:

// Le modèle ne produit jamais d'écriture directe : il produit une intention
// typée, que le serveur valide contre le schéma avant de toucher la base.
type Command = {
  intent: "create" | "update";
  entity: "client" | "case" | "hearing" | "note";
  fields: Record<string, string>;
  // Ce que l'utilisateur voit avant que quoi que ce soit ne soit écrit.
  confirmation: string;
};

Mapping free text onto a schema that has foreign keys, required fields and tenant boundaries is where the real work is. And a write that happens without confirmation is a bug, not a feature — in a tool where the data is someone's case file, silent writes are unacceptable. Every command surfaces what it is about to do and waits.

The same rule applied to the client-facing side: the assistant helped people understand where their case stood, and never substituted itself for the lawyer's advice. In this profession that line is not a product decision, it is the condition for being allowed in the room at all.

Once that contract exists, adding commands is cheap. Which brings the paradox back for a third time: I added a lot of them. Most went unused. The two or three that mattered would have been a better product than the twenty that existed.

GDPR is not a checkbox when your users have professional secrecy

The backend was built from the start around French and European data rules: lawful basis, retention limits, real deletion rather than a soft-delete flag, encryption, access logs, and the ability to export or erase a client's data on request without a manual database query.

Then there is the AI question, which for this audience is not a technical detail. A lawyer is bound by secret professionnel. If a case file transits through a model provider that retains it, that is not a compliance risk — it is a professional one, and it ends the conversation. So I signed a Data Processing Agreement with OpenAI covering zero retention and no training on customer data, and I could say so in writing.

Doing that early was the right call, and it is the piece of the build I would keep verbatim on the next project. Not because it sold anything, but because without it there was nothing to sell.

The Doctolib play: a million impressions and no business

Here is the ambitious part, and the one that failed most interestingly.

The idea was borrowed from Doctolib's early shape: instead of selling software to professionals cold, first become the place where their clients look for them. I would capture justiciables — people searching for legal help — through SEO, build real traffic, then call lawyers and say: I am already sending people looking for someone like you. Want to try Lexlane while I do it?

The SEO worked. Around a million impressions from France in three months, and it is still growing.

The business did not. A few things I got wrong:

Impressions are not intent, and intent to find a lawyer is not intent to buy software. I had built an audience on one side of a marketplace and tried to convert it into revenue on the other, which only works if the traffic is large enough and qualified enough that a lawyer feels the absence of it. Mine was neither, yet.

The two sides also run on different clocks. Consumer search traffic compounds over months. A law firm's software decision happens once every several years, usually at a renewal date, usually under advice from the same people who sold them the last one. Arriving with traffic in month three of a cycle that turns over in year five is arriving at the wrong time with the right argument.

And the call itself was weaker than it sounded. "I brought you traffic" is a favour, not a product. Favours do not survive procurement.

What I would do differently

Sell before building. Not a landing page with a waitlist — an actual conversation where someone says a number out loud. I could have learned the purchasing power problem in a week of phone calls instead of a year of engineering.

Pick one job, not a vertical. The thing a narrow tool gets that an all-in-one never does is the right to say no.

And check that the market can pay before checking that it is large. I got that order backwards, and everything downstream inherited the mistake.

Lexlane is not the story of a build that went wrong. The build went fine — that is precisely the problem. It went so fine that I never had to stop and ask whether it should exist. When the cost of building drops that far, nothing stops you early anymore. You have to stop yourself.