How Booking.com Built a Culture Where Anyone Can Ship a Test

What Booking.com actually does

Booking.com is an online travel marketplace: the site and app people use to search for a place to stay, compare options, and book a room. What's less visible is what sits underneath every one of those screens. The search results page, the property listing, the checkout flow — each one is a live product decision that Booking's teams are constantly trying to improve. Does this layout convert better? Does this wording confuse people? Does a different price presentation change what people actually do?

At a company operating across dozens of markets, those questions can't be settled by opinion or a strong internal argument. They get settled by testing a change on real traffic and measuring what happens. That habit, tested first, decided second, is the whole story here.

The story

In the mid-2000s, a small team of Booking.com's own engineers, working out of Amsterdam, built the tooling to run those tests. Not because building in-house was the preferred strategy, but because there wasn't really anything to buy yet. The market for dedicated experimentation platforms hadn't matured. So they built one, kept extending it rather than replacing it, and it still runs the company's testing today.

By the time commercial tools like Optimizely reached the market, Booking's internal platform was already carrying tens of thousands of tests a year and was wired into how every product team measured whether its work actually worked. Switching to something bought off the shelf stopped being a live question — not because the vendor tools were bad, but because unwinding something that deeply embedded would have cost more than any new tool could offer back.

Here's the detail that makes the rest of the story make sense. At Booking.com, shipping a test doesn't require a committee, a quarterly planning cycle, or a director's sign-off. In a paper Booking's own engineering and data science team published on how they democratised the platform, they describe deliberately opening test creation up beyond engineering, to product managers and beyond, so that testing wasn't a scarce resource gatekept by a small central team. According to HBR's reporting, a new hire can be running a live experiment in front of millions of travellers within their first few weeks on the job.

That sounds like it should be reckless, and it's the part of the story worth slowing down on. None of that access was handed out until the safety net underneath it existed first. Long before anyone could self-serve a test, Booking's engineers had to do the unglamorous work of making that safe: statistical guardrails, automated monitoring, and infrastructure built specifically to support safe experimentation at scale. Vermeer, one of the engineers behind the platform, has written about its "circuit breaker," a system that watches every live experiment for serious errors or sudden drops in performance and can automatically kill a release within seconds, no human required.

New hires don't just get a login. Onboarding covers both how to design a sound test and the ethics of running one on real customers, not as a formality bolted on afterward, but because the company chose not to set up a separate ethics review board to slow decisions down. Booking's chief product officer at the time put it plainly: he'd rather stay away from "policing or ethical review boards," because that doesn't scale and it makes people feel policed rather than trusted. The company built a self-correcting culture instead of a gatekeeping process.

What this teaches

It's tempting to read "anyone can ship a test" as a culture decision — a looser, more trusting way of working that any company could copy by simply deciding to trust people more. That's the easier half of the story, and it's incomplete. The freedom Booking's teams have today sits on top of years of unglamorous infrastructure work: guardrails, monitoring, training, and a platform that was built once, properly, and never had to be torn out and started over.

Hand the same access to a team without that infrastructure underneath it, and the result isn't Booking's culture. It's a company one bad test away from a real incident.

That's the actual lesson here: not "give your team more autonomy," but check whether the thing making your team's speed safe was actually built, or whether you've just been lucky so far. The same question applies whether you're running experiments, deploying code, or giving any individual more access than they've previously had.

Booking's twenty-year run on a platform it never fully replaced is close to the inverse of a pattern TechTek has written about before: founders who ship fast on a vibe-coded MVP, mistake early momentum for a stable platform, and find themselves needing to rewrite far sooner than they expected. Read Don't Rewrite Your Vibe-Coded App Too Early for the other side of that story. The foundation got built properly at Booking, early, and that decision is still paying for itself two decades later.

The question worth asking isn't whether your team can move fast. It's whether the thing making that speed safe actually exists yet, or whether everyone's just being careful so far.