Hey, I’m Timothe, cofounder of Stellar & based in Paris.
I’ve spent the past years helping 500+ startups in Europe build better product orgs and strategies. Now I’m sharing what I’ve learned (and keep learning) in How They Build. For more: My Youtube Channel (🇫🇷) | My Podcast (🇫🇷) | Follow me on Linkedin.
If you’re not a subscriber, here’s what you’ve been missing:
How Front is turning product teams into AI-powered growth engines
Inside Amplitude’s journey to enterprise-scale Product analytics
Company backstory
Alan launched in 2016 with a mission to make healthcare more proactive, transparent, and easy to use. Over the years, the company expanded beyond insurance into a broader health platform focused on prevention and daily care.
The company now generates more than €785M in annual revenue, serves over 1 million members, works with more than 35,000 companies and public organizations, and employs close to 800 people across four countries. Last week, Alan announced a €480M Series G funding round, bringing its valuation to €5.5B. Led by Prosus, the round will accelerate the company's international expansion, deepen its investment in AI, and support its ambition to make prevention, not treatment, the global standard for healthcare
Alexandre Gerlic joined Alan in 2019 when the engineering team counted around 20 people. Since then, he helped scale it to more than 100 engineers while keeping a strong culture of distributed ownership and autonomy.
I sat down with Alexandre Gerlic, VP Engineering at Alan, to discuss how AI transformed the way Alan builds products, how non-engineers now contribute directly to production systems, and what this changes for product organizations at scale.
Disclaimer: The organizational choices and technical solutions shared in this newsletter aren’t meant to be copied and pasted as-is. Always keep your company’s context in mind before adopting something that works elsewhere! 😊Build internal AI champions before scaling adoption
Alan started working seriously on AI before ChatGPT became mainstream. The initial push came directly from the founders, who believed AI would reshape every function inside the company.
Alan identified employees already experimenting with AI tools in their daily work and encouraged them to help drive adoption inside their teams. These people progressively became internal “champions” across the organization.
The company then gave them time, access, and resources to test workflows specific to their own domains:
sales teams explored sales workflows
designers explored creative workflows
product teams explored prototyping
engineers explored coding assistants
This helped AI adoption spread naturally through peer-to-peer learning.
One of the earliest examples was surprisingly simple. Alan created a Slack bot capable of generating new versions of its marmot mascot instantly. Employees could request variations directly inside Slack and immediately see the result.
The experiment looked playful at first, but it helped teams understand how fast iteration could become with AI tools.
“We had 800 people using AI every day across all functions” — Alexandre Gerlic
This first phase created an important mindset shift. Teams started asking themselves how AI could improve their own workflows instead of waiting for a formal transformation plan.
Give every team access to the same development environment
One of Alan’s most important decisions was giving non-engineers access to the same development environment used by engineers.
The company first tested this approach with operations teams working on internal tools. Employees wanted to improve small workflow frictions that rarely made it into engineering priorities, such as changing dropdown orders or fixing repetitive UI issues.
Alan then created an initiative called “Everyone Can Build.”
The company extended its existing engineering environment and workflows to business teams so everyone could collaborate inside the same system:
same codebase
same development setup
same review process
same deployment standards
same quality systems
This created a shared operating model across engineering, product, and design.
The goal was also to keep collaboration loops tight. Improvements made for engineers could immediately benefit designers and PMs, and vice versa.
“The counterintuitive choice we made was deciding not to use new tools” — Alexandre Gerlic
The rollout happened progressively. Designers adopted the workflow first, then started helping other designers learn the system. Later, PMs and other teams began contributing directly as well.
Over time, product conversations became more execution-oriented. Instead of opening tickets for every idea, teams could prototype and test improvements directly inside the product environment.
Use strong guardrails to let non-engineers ship safely
Opening production workflows to non-engineers required a strong infrastructure layer underneath.
Alan first limited contributions to frontend changes. This reduced operational risk while still allowing teams to work on visible product improvements.
The company then reused all existing engineering safeguards:
linters
code validation systems
deployment checks
code reviews
development environments
These guardrails became essential to scaling the initiative safely.
Alan heavily customized its Cursor environment to support non-engineers. One important addition was an assistant capable of estimating implementation complexity. This helped designers and PMs understand whether a requested change was simple or required deeper engineering work.
The company also optimized feedback loops. Teams could modify interface elements conversationally and instantly visualize the impact inside the application.
This made experimentation much more accessible for non-engineers.
“When people realized they could modify tools they use every day, there were stars in their eyes” — Alexandre Gerlic
One interesting outcome was that AI-generated pull requests sometimes improved existing systems automatically. In one example, an internal tool migration toward Alan’s newer design system happened during a simple interface modification.
Shift product discussions from capacity constraints to ambition
As implementation costs decreased, Alan noticed a change in how teams discussed prioritization.
Previously, many product decisions depended heavily on engineering bandwidth. Some improvements stayed low priority because the implementation effort felt too high relative to impact.
AI changed that equation.
Small bugs and workflow frictions became easier to address quickly. Teams could test ideas faster and move from concept to implementation with less coordination overhead.
This progressively changed the nature of product discussions.
Teams started focusing less on whether they could build something and more on where they wanted to invest ambition and focus.
The impact also appeared in team structure. Alan historically preferred small autonomous teams. With AI-assisted workflows, the company is now exploring whether some initiatives can start with only two people.
This affects:
experimentation speed
coordination costs
ownership models
team composition
roadmap flexibility
At the same time, new constraints appeared elsewhere in the workflow:
code review
validation
testing
deployment speed
product consistency
Alexandre explained that accelerating one part of the product development cycle naturally increases pressure on the following stages.
Alan is now exploring workflows where AI supports not only code generation but also validation and review processes.
Turn operational knowledge into reusable AI skills
As AI models improved, Alan shifted attention from pure code generation toward reusable organizational workflows.
The company started building “skills” capable of encoding internal knowledge and processes:
reporting standards
operational workflows
product conventions
business context
engineering practices
These skills can then be activated contextually by AI systems when needed.
One example Alexandre shared was reporting.
Alan created a workflow capable of gathering information automatically from Slack, GitHub, and internal systems to generate weekly reports for individuals and teams.
This reduced the amount of repetitive operational work employees needed to perform manually.
“The logistical aspects are increasingly handled by AI, and I review where I bring the most value” — Alexandre Gerlic
The interesting part is that these workflows are reusable and improve over time. Teams progressively turn recurring operational tasks into scalable internal systems.
This approach also helps distribute organizational knowledge more consistently across teams.
Avoid forcing metrics too early during AI adoption
Alan intentionally avoided over-measuring AI adoption during the first stages of the transformation.
According to Alexandre, introducing the wrong metrics too early could create poor incentives:
too much focus on output volume
reduced experimentation
lower quality contributions
artificial productivity comparisons
Instead, the company first focused on qualitative signals:
are designers prototyping directly in production?
are PMs testing ideas faster?
are teams fixing issues more autonomously?
are workflows changing naturally?
Only later did Alan start adding more operational metrics around AI-generated code and workflow performance.
The company also began analyzing whether AI-generated pull requests actually moved faster through production workflows or introduced additional review complexity.
This iterative approach allowed teams to adapt workflows before optimizing them heavily.
It also reduced the risk of freezing behaviors too early while the tooling ecosystem itself was still evolving rapidly.
One of the biggest challenges was navigating unstable tooling
One of the most difficult moments for Alan came during the early wave of AI coding assistants.
Alexandre described a period where online discussions around AI were moving much faster than the actual reliability of the tools available internally. Teams saw potential, but many workflows still felt inconsistent and immature.
This created uncertainty inside organizations.
Some early experiments produced useful gains, while others delivered limited impact. Teams had to continue iterating while the underlying models and tooling improved rapidly month after month.
According to Alexandre, one important learning was staying flexible organizationally. Alan continuously changed tools, workflows, and environments as the ecosystem evolved.
The company also invested heavily in internal learning loops:
testing new workflows quickly
sharing learnings across teams
iterating on training
adapting environments continuously
This helped the organization evolve alongside the technology instead of waiting for a perfectly stable setup before moving.
The broader takeaway is that AI adoption requires continuous organizational adaptation, especially when workflows and tooling are still evolving very quickly.
Adoption spreads faster when each team develops workflows adapted to its own operational context and constraints.
Shared tooling environments create stronger collaboration loops between engineering, product, and design teams.
Strong engineering guardrails become essential when non-engineers start contributing directly to production systems.
AI reduces implementation friction, which changes how teams think about prioritization and product ambition.
Smaller autonomous teams become increasingly effective when AI reduces coordination and execution overhead.
Reusable AI skills can progressively transform operational knowledge into scalable internal infrastructure.
Qualitative workflow changes are often better indicators than productivity metrics during the first stages of AI adoption.
Organizations need fast iteration loops because AI tooling and capabilities evolve continuously.
Product development workflows increasingly combine ideation, prototyping, and implementation inside the same operational environment.
AI transformation requires organizational adaptation as much as technical experimentation.
My full interview with Alan VP Engineering
Dive deeper into this topic with Alexandre Gerlic, VP Engineering of Alan, in my latest podcast episode:
Enjoyed this newsletter? Share it with your network using the button below—your support means a lot!