Graham McNicoll

If you are an engineering leader at a growth-stage company currently maintaining your own experimentation platform, this is the Dropbox story you should read before your next build-versus-buy review. Dropbox runs 3 billion feature evaluations a day. For years, that ran through a stack of internal tools the team had built. It worked until the company outgrew it. The system did not break, but the maintenance cost started to compound. This is the part teams miss when they decide to build. The initial build can be straightforward, but what you have actually signed up for is owning that system that requires constant maintenance and improvements. Tech stacks change, needs change, and as this happens, all the systems around your product need to change too - your home built experimentation platform is no exception. Dropbox's team inherited Python, PHP, and other languages. Every new product team has requirements that stretched the original technology. New AI products needed rapid iteration, staged rollouts, and fast rollback. Each of those is a separate piece of bespoke engineering on a system the team is also trying to keep running. At Dropbox, the bill eventually looked like this: - Tool sprawl across multiple internal and third-party systems, each with different workflows - Experiment analysis taking days, often requiring custom notebooks or bespoke pipelines - A diverse technical ecosystem the legacy system was never designed to work with - Engineers maintaining infrastructure instead of building products They moved to GrowthBook, self-hosted on AWS, with analysis running directly on their Databricks data lake. The migration was easy: new experiments built in GrowthBook, and legacy experiments left to run their course in the old systems. After the move: - Setup for a new experiment dropped to about an hour - Engineers and data scientists build experiments directly, instead of routing through bespoke pipelines - 30 to 50 experiments run monthly across the company - Two internal tools are being retired, with consolidation continuing I built GrowthBook because I watched this pattern repeat. Teams make a reasonable build decision, and three years later a new engineering manager is trying to work out whether to keep maintaining a system the original authors have long since left. The build-versus-buy question is framed as a cost comparison. It is not. It is a question of what you want to own for the foreseeable future. Read the full Dropbox migration at https://lnkd.in/g8EPSgyf, or send me a DM if you want to talk through what it would look like for your team.

Only one snapshot so far — the engagement-over-time curve appears once the daily scrape has captured this post at least twice.