Architecture & Scale

PubliSpeak.

From a proof of concept to a microservices SaaS platform, without losing a client or interrupting service. A gradual migration organised around business domains.

9 years

of continuous organic growth

What was at stake.

PubliSpeak started at Ipedis as a proof of concept. I built V1 from scratch, a paper-document digitization platform that became one of Ipedis’s flagship products.

The platform is trusted by companies like Air Liquide, L’Oréal, Publicis and Groupe Premium through Ipedis. The challenge: evolve the architecture without disrupting service for clients who depend on it daily.

The team grew from 5 to 25 during this period. We had to scale the architecture and the organization at the same time.

What needed to change

A monolith starting to show its limits. The team was growing from 5 to 25 and the architecture couldn’t keep up.

Every new feature became riskier. Clients depended on the platform daily, leaving zero margin for incidents.

In their words.

Yanis managed to grow the product and the team simultaneously. 9 years of growth without a major incident or a missed deadline is rare.

JackirManaging Director, Ipedis

The choices I had to argue for.

1
Decision 1
Incremental migration to 10 microservices using a DDD (Domain-Driven Design) approach. Each business domain was isolated gradually, no big bang.
2
Decision 2
RabbitMQ event bus for decoupling. No service interruption throughout the migration: clients never noticed.
3
Decision 3
Alongside the migration, I hired new team members and organised responsibilities. We introduced structured onboarding and shared knowledge as the team grew.

What changed.

Architecture
BeforeMonolithic POC
After10 microservices
Team size
Before5 people
After25 people
Production
AfterNewZero major incidents
Growth
AfterNew10%/year for 9 years

The takeaway.

I could have argued for a dramatic rebuild. We chose to separate domains one at a time while clients kept working. I prefer that patience: an architecture needs to evolve without making users bear the cost of every change.

To structure your team and its decisions over time, explore my fractional CTO support.

Facing a similar challenge?

Discuss your situation

Next case study

3,000+

audits completed for 200+ clientsIpedisConnect™

Latest articles

Growing an engineering team without growing the queue

The Ipedis product team grew from 5 to 25 people. A look at the responsibilities, hiring, onboarding and dependencies that needed attention during that growth.

Blog