Managed Infrastructure

Lines of code are becoming a commodity. As code generation models improve, it will become easier and easier to build software products.

That does not mean building good software becomes trivial. It means code itself becomes less of a moat. Distribution, execution, product judgment and strategy matter more.

Yet I still see early-stage teams prematurely optimizing for scale and building complex cloud environments before they have much of anything to scale.

For a startup engineer, the main job to be done is to build things that help the company find and strengthen product-market fit.

PMF is not a binary destination. For much of a startup’s first few years, you are continuously finding it, strengthening it and expanding it into larger markets. During this period, learning velocity and revenue growth usually matter far more than optimizing infrastructure margins.

The major cloud providers are incredibly powerful, but much of their underlying model was designed for infrastructure and platform engineers. IAM, networking, security policies, deployment infrastructure and dozens of interconnected services give you enormous flexibility, but they also create enormous surface area.

Most application engineers do not need that flexibility on day one.

Over the last several years, independent managed infrastructure has become good enough that much of this work can simply disappear. Vercel for compute and deployment. Neon for Postgres. Clerk for authentication. Similar products now exist across observability, queues, storage, email, payments and most of the infrastructure an early-stage software company needs.

You can increasingly get strong security, compliance and reliability without owning every layer of the stack yourself. This is my default stance for early-stage teams:

Use managed infrastructure. Pay the markup. Accept some platform dependence. Spend the engineering time you saved talking to customers, shipping product and finding distribution.

A good rule is to move down the stack only when the abstraction above it becomes a meaningful constraint.

Cost can be that constraint, but so can performance, reliability, security, control, data residency or developer velocity. Until then, owning more infrastructure is often paying engineering salaries to save infrastructure dollars.

And when that constraint appears, you can own the part of the stack that matters. You do not need to preemptively own all of it.

You can become opinionated about infrastructure purity, cloud margins and your OSS values after you have done the main job to be done: found a massive market and won a meaningful part of it.

This is particularly relevant to the DHH fanboys spinning up Linux boxes on Hetzner because running your own infrastructure is supposedly simpler and cheaper.

Maybe it is.

But if your startup has $500k in revenue, saving 40% on a $5k monthly infrastructure bill is probably not the highest-leverage problem your engineers could be working on.

There are obviously exceptions. Defence tech, regulated environments, unusual data residency requirements, extreme compute workloads and products where infrastructure itself is part of the competitive advantage can justify owning more of the stack much earlier.

The point is not that managed infrastructure is always better. The point is that complexity should be earned.

At Durable, I am happy to push this philosophy quite far. We are building heavily on the Vercel AI Cloud because I would rather have engineers solving product problems than recreating infrastructure abstractions that already exist elsewhere.

If you do not yet have tens of millions in revenue, millions of users or some compelling technical constraint, you probably do not have a scaling problem.

You have a product, execution or distribution problem.

Act accordingly.