Developer-Led Docker Adoption

Diving deeper into

Joe Zeng, software engineer at Statsig, on using Docker

Interview
Devs generally make the decision to purchase tools at Statsig. We just put down a company card.
Analyzed 6 sources

This buying pattern shows why developer infrastructure companies can grow fast without a formal CIO sale. At a startup like Statsig, the engineer who feels the pain also controls the spend, so a low priced tool like Docker gets adopted with almost no internal process. That works because Docker is a tiny line item, easy to justify on productivity, and already sits inside the team’s daily build and deploy workflow.

  • Statsig ran a fairly standard modern startup stack, Azure, AKS, Node.js, Redis, MongoDB, Databricks, and used Docker as part of a Kubernetes based workflow. In that setup, the buyer is naturally the engineering team because they are the ones building images, pushing them, and dealing with deployment friction every day.
  • Docker rebuilt its business around this exact motion. Instead of asking ops teams for an enterprise contract, it first got individual developers and development managers to pay by card for low cost seats, then used that usage to expand into larger team purchases. That shift helped Docker scale from about $11M ARR in 2020 to about $135M in 2022.
  • The contrast with Vercel and Netlify is simplicity versus control. Those tools win early because they make a web app go live with very few decisions, but teams running many services on Kubernetes still need deeper control over networking, resource limits, registries, and custom infrastructure. That is why startups often use both patterns at once, Vercel for simple front end projects, Docker and Kubernetes for heavier backend systems.

Going forward, more infrastructure spending will start as developer card swipes, then graduate into manager approved expansion once usage becomes large enough to need invoicing, security controls, and centralized visibility. The winners will be the tools that feel effortless on day one, but still leave enough room for teams to scale into more complex workloads without ripping anything out.