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 early-stage teams still prematurely optimize for scale and build complex cloud environments before they have much of anything to scale.
The job is product-market fit
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.
Rent the plumbing
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 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.
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. When a real constraint appears, own the part of the stack that matters. You do not need to preemptively own all of it.
Complexity should be earned
You can become opinionated about infrastructure purity, cloud margins and your open-source 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.
Our stance at Durable
At Durable, we push this philosophy quite far. We are building heavily on the Vercel AI Cloud because we 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 probably have a product, execution or distribution problem. Act accordingly.