Case study
52 engineers across 3 countries
How we scaled a SaaS platform with a distributed team and AI-assisted development.
Before
A B2B SaaS platform with hundreds of thousands of business customers and more than 10 million active users, led by an engineering organization of 52 people working across regions. Scale was real. The operating experience of the product and the team was not keeping up with it.
Friction
Work was spread across a distributed team without a shared way to decide architecture, quality and what “done” meant for an operational flow. Local speed created inconsistency. Leaders could see activity and still not see whether the platform was getting easier to run.
Result
On the published record of that work: net promoter score moved from about 60% to about 85%. Time spent on an operational task fell by about 40%. Clicks inside a key flow fell by about 20%. The gain was not a new slogan for scale. It was a tighter system of engineering decisions on a platform that was already large.
This case stays anonymous on purpose. The figures are the ones already stated in the public description of the work: 52 engineers, a multi-tenant B2B platform, more than 10 million active users, and a shift in NPS, task time and clicks.
What leadership had to install
Distribution is not a location problem. It is a decision problem. A team of that size, working across regions, needs explicit standards for architecture, review and the operational flows customers actually touch. Without them, each group optimizes a local queue and the product accumulates small divergences that users feel as friction.
The work was modernization and execution at that scale: event-driven architecture, a data warehouse, and engineering standards that made quality discussable instead of personal. AI-assisted development belonged inside those standards — useful for drafting and accelerating work the team already knew how to judge, not a substitute for the judgment.
Why the numbers matter
NPS moving from about 60% to about 85%, task time down about 40%, and clicks down about 20% are not a feature list. They are evidence that the operating experience moved. That is the standard I still use: a change in how the system feels to run, not a count of initiatives completed.