Lexroom is a platform that uses artificial intelligence to revolutionize legal research. Instead of making lawyers waste hours in endless case law databases, their system analyzes documents, finds relevant precedents, and generates precise answers in real-time.

Their target? Law firms and professionals who want to work faster without compromising accuracy.

TL;DR - Key Results

• €500K pre-seed → €16M seed round in less than 2 years
• Company size: 3 → 15
• Complete operational autonomy after 6 months of collaboration

When the problem isn’t technology

Paolo reached out to me again at the end of 2023. We had met months earlier during my time at zerocento, we had built a connection, and when I went independent as a Fractional CTO we started talking again.

Lexroom had everything needed to start well: three strong co-founders, fresh from the Vento accelerator in Turin with an MVP already in development and initial market validations.

There was Andrea, their CTO, incredibly strong on the AI side (the technological core), then Paolo (CEO) who handled product and Martina ready to go on the commercial side.

But what I understood immediately in the first call was this: they didn’t have a technical skills problem, they had a focus problem.

They were developing features without direction, they didn’t have a clear methodology to decide what to build and when. And above all, they had limited resources (time, budget, people) and risked burning them on the wrong things.

“We need someone to help us figure out what to really focus on” Paolo told me in that first meeting.

They weren’t looking for a replacement CTO. They were looking for someone who would bring discipline, methodology, and the ability to say NO when needed.

The NO that changed the trajectory

I spent the first month analyzing their stack, the roadmap (or rather, the infinite list of “we’d like to do”), and talking with all three founders to understand where they wanted to go.

The first big decision came right away, and it was the hardest.

Andrea and the team wanted to completely redo the backend and the artificial intelligence engine.

They weren’t satisfied with the accuracy of the responses, and in the legal sector this is a critical problem. Lawyers don’t forgive errors or inaccuracies.

Technically? They were right. The engine could be better, the architecture cleaner, everything more scalable.

But strategically? It was the wrong time.

They didn’t yet have a solid customer base to validate whether the problem was really the AI engine or something else.

They didn’t have the financial resources to afford 3-4 months of development without releasing value.

And above all, there were features that early customers were asking for loudly and that could unlock new sales.

The compromise we found was this: postpone the refactoring, focus on customer-requested features to validate the market, and build the methodological foundations that would make future refactoring easier and faster.

It wasn’t an easy conversation… Telling a brilliant CTO that their legitimate technical concern must wait requires tact, mutual trust, and above all data.

But Andrea understood the logic, and together we chose the path that would deliver more value in the short term without compromising the long term.

Building the machine, not just the product

Once that strategic decision was made, we focused on two parallel fronts: team building and product methodology.

On the team side, I brought on board two developers and a freelance product designer selected from my network. We weren’t building a permanent team at that stage, but people who could accelerate MVP development while maintaining quality and speed.

Every person went through a selection process.

I wanted profiles that would integrate well with their technical vision, not replace it.

On the methodology front, we did deeper work than it seems.

Before my arrival, Lexroom was working without a structured roadmap…

Feature requests came from customers, investors, the founders themselves, and were added to a growing list without clear prioritization.

I introduced a classic Kanban methodology but applied with discipline:

• Weekly backlog refinement where we discussed all new requests
• Prioritization based on business impact vs technical effort, always consulting with Martina on the commercial side
• Clear sprints with measurable objectives and end-of-cycle reviews
• Retrospectives to improve the process itself

We did workshops together, hands-on sessions where all founders were involved. I wanted Paolo and Martina to understand the “why” behind technical choices, and Andrea to understand business constraints and opportunities.

The result? In 5 months we went from “let’s do everything” to “let’s do this, then this, then we’ll see.”

And that clarity unlocked everything else.

The results speak for themselves

About 3-4 months after the start of our collaboration, Lexroom closed a €500K pre-seed.

I didn’t participate directly in the round, but the work done together (the clear roadmap, the structured team, the product discipline) made everything more solid and due diligence easier.

But the real result came later.

In September 2025, Lexroom closed a €16M round.

Today they have paying customers, a constantly growing team, and operations that run without my continuous involvement.

They still write to me, for example a few weeks ago they asked my opinion on a tech profile in the interview process, but they’re completely autonomous. And this, for me, is the most important metric.

What I learned from them

Lexroom was one of the first startups that believed in me as a Fractional CTO.

And for that reason, I care about it particularly.

But what struck me most was their ability to listen and trust.

When I tell you that saying NO to the refactoring wasn’t an easy conversation, I’m talking about founders who had a strong technical vision and had to accept postponing something they considered important.

That level of mutual trust made everything else possible.

I learned that the best way to work with competent founders is not to replace or overlap them, but to support them with a complementary perspective. Andrea knew more about AI than I ever will, Paolo had a crystal-clear product vision, and Martina understood the market better than anyone.

My role wasn’t to teach them how to do their job. It was to bring external discipline, a decision framework, and the ability to say “yes to this, no to this, this later”.

And in the end, that’s exactly what made the difference.

The decisive factors

• Focus beats perfection, always. Saying NO to a technically correct but strategically premature refactoring saved months of development and unlocked growth. Technology follows business, never the other way around.
• Methodology is an underrated competitive advantage. In early-stage phases, having a clear roadmap and prioritization discipline is worth as much as having a good product. Without structure, even brilliant teams burn resources.
• A Fractional CTO doesn’t replace anyone, they enhance. Even with a competent internal CTO, a Fractional can bring complementary capabilities (team building, methodology, strategic decisions) that accelerate growth without creating conflicts.

Lexroom today has what few startups achieve in such a short time: a validated product, paying customers, €16M in the bank, and a team that knows exactly where it’s going.

For founders reading this

Limited resources are your real competitive advantage. They force you to make difficult choices, to say NO, to focus only on what really matters. But this only works if you have a methodology to decide what matters.

Having internal technical skills doesn’t mean you don’t need external support. If you have a strong CTO but feel that focus, discipline, or ability to scale the team is missing, a Fractional CTO can be the complement that unlocks everything without creating overlaps.

The right time to do the right things really exists. Redoing the backend can wait. Scaling infrastructure can wait. What can’t wait is validating the market, acquiring customers, and building a product machine that runs without chaos.

The question isn’t “what should we build?” but “what should we build now?”