Startup to Enterprise: what 7 countries taught me
Two years at Decathlon shipping to 7 countries. What stuck with me wasn't the code: it was what breaks when you get it wrong.
I have been building digital products for five years now, and I have had the chance to see a bit of everything.
First the organized chaos of startups, where you touch everything because there is nobody else to do it. Then the pace of web agencies, where the next project starts before the last one ships. At IVS, I was the resident Swiss Army knife: a critical prod bug in the morning, a technical interview in the afternoon, and the next day at a booth in Lille pitching the app to visitors. A great way to learn. But you skim everything, all the time.
In September 2024, I set up camp at Decathlon Digital as a freelancer.
I was nervous. Not about the code, about the scale.
For nearly two years I worked with the Teamwear team (called ODVC before, then MyClub after). Our mission: a headless e-commerce platform for sports product customization, aimed at professional customers and clubs.
Concretely, a club shows up with its logo, puts it on a jersey, picks its colors, and orders for forty players with a name and a number on each piece. All of it across seven countries: Germany, Spain, Italy, France, Belgium, Poland and the Netherlands.
That last sentence is what changed everything for me.
What focus changes
But before getting there, something unexpected happened: for the first time, I had a single subject.
Time to grind Next.js until it had no secrets left. Cutting build times down. Switching a route to dynamic just by reading a cookie. Dissecting how Next optimizes images (WebP, AVIF, the sizes attribute). Mutating the server cache with Server Actions.
Put like that it sounds trivial. It is not. When you spend two years on the same tool, you stop searching Stack Overflow and start understanding why it was built that way.
The playground helped. On the front end, Next.js 16 and React 19 for real-time customization. On the back office, Shopify, wired up headless through its GraphQL Storefront and Admin APIs. And holding it all together: TypeScript, a unit testing strategy with Vitest, and a CI/CD pipeline on GitHub Actions.
On top of that, Unmade handled design rendering, and it is a good example of what focus buys you. Unmade generates the customization image, which means our application never owns the final visual of the product it sells. Working out where our responsibility ends and theirs begins takes time. The kind of time you do not have when you are juggling three projects.
Knowing that ground is what let us take on the V2 with Medusa, the open source alternative to Shopify.
The point was never to chase a trend, but a limit we knew by heart from working around it. A jersey with a club logo, a size, a number and a name is not a catalog item: it is a combination, and it is nearly unique on every order. Shopify thinks in predefined variants. We needed to model the customization itself. Medusa, which we host and extend ourselves, let us do that.
On the mission I worked on one part of Medusa. I wanted to see the rest, so I built my own e-commerce in the evenings, from the product page all the way to checkout.
A monorepo, Next.js 16 for the storefront and Medusa v2 for the back end, with PostgreSQL and Stripe for payments. The whole thing runs on a Hostinger VPS, containerized with Docker.
The hosting part is what taught me the most. On a mission, you push to a branch and the platform handles the rest. On your own VPS there is nobody behind you: you write your Dockerfiles, you manage your database, you find out why the container keeps restarting at two in the morning. Rebuilding alone what a team does together is the best way to see everything you were not doing yourself.
A quick flex
Lines of code mean nothing. I know that.
But after two years building this headless architecture, I ended up on the podium of the project's top contributors. I look back at it with a little smirk.

That is not what stuck with me.
Seven countries, seven ways to break things
What stuck with me is what happens when you get it wrong.
At a small scale: you code, you break something, you fix it. Nobody notices.
At Decathlon, one dumb mistake ships to seven countries, with seven catalogs and seven sets of business rules. You are not breaking your bit of code. You are breaking the day of people you have never met.
I understood that by watching how we handled support.
At first you have the hero dev reflex: a country reports a bug, you jump in, you fix it live. You feel useful.
It is a mistake. As soon as a country works out that you patch their problems instantly, you become their personal tech support. And that is all you do from then on.
What unlocked the situation was a strict ticketing system run by the PMs. Frustrating at first. Except the goal was no longer to answer fast, but to see the whole picture: this bug reported by Spain, does it hit Italy too?
Shipping every day
Once that reflex was fixed, the question everyone dreads was still there: how do you deploy without blowing everything up?
We could have gone country by country, carefully. We did the opposite: everyone at once, all the time.
Our releases were named 26-07-30. Year, month, day. The name alone states the intent, ship as often as possible. The PM validates, we push to all seven countries at once.
It sounds risky. It is the opposite. When shipping to production becomes a boring routine, it stops being scary. What is scary is the deploy you have been putting off for three weeks that carries forty changes.
i18n is not translation
Deploying everywhere at once has a flip side: the product has to make sense everywhere at once.
Translating text is easy. Formatting dates, a library handles it.
Per-country business rules are another story.
Italy already had mandatory electronic invoicing when the others had not even heard of it. That is not a translation string, it is a format, a transmission channel and legal mentions to comply with, for one country out of seven.
Belgium wanted to showcase its clubstore section, the others did not. Same code, same deployment, but an experience that had to differ. We went with a feature flag system: each country turns on what makes sense for it, without us maintaining seven versions of the application.
None of that factors out. You document it, you test it (bless Vitest and GitHub Actions), and you pay for it on every new feature. Forever.
That is when I started looking at the product differently. These rules do not come out of a config file, they come out of conversations with people who know their market.
The retro that taught me the most
My biggest wake-up call did not happen in VS Code.
I took the initiative to host the team's retro. Sprint 33. Christophe and Mehdi were flying out to the US, so I ran a special edition entirely in English. No pressure, no judgment.

Preparing that ceremony forced me to take off my developer hat. How real velocity is calculated. Why a sprint goal matters more than a closed-ticket counter. What the team lives through that I could not see from my editor.
One hour of preparation taught me more about the product than three months of code.
What I took with me
The strangest part is that all of it followed me into my personal projects.
I used to run in two modes. Agile, Jira and process at work. Pure improvisation on weekends.
I merged the two. For Prospect Tracker, my SaaS, I work with the same rigor as at Decathlon.

That board is the same one a team of ten would use. I create sprints, I set goals, I leave comments on my own tickets for my future self, the one who will have forgotten everything in three weeks.
I also run solo retros. Yes, alone, with myself. If I miss a goal, I look for why. If I crush it, I ask whether I aimed too low.
And I write ADRs, Architecture Decision Records. I picked that up from the Decathlon Design System team. Writing down why I chose a stack stops me from reopening the debate every six months whenever a trend shifts.
Two years at Decathlon taught me how to build solid platforms. But mostly that the code is never the hard part. Understanding the product and the organization around it is what separates a dev who executes from a dev who has impact.
That works anywhere. Even when your only user is you.
More posts

The Tailwind class that never applied
Tailwind generated it, TypeScript validated it, ESLint said nothing. It simply had no effect. The bug was in the name I had chosen.
3 min read
Next or TanStack? That's not the question
I spent hours comparing frameworks. None of it brought me a single customer. What decides a SaaS is distribution, and it starts before the first line of code.
7 min read