Managed platforms get you to market. Proven primitives keep you there.
Supabase and Vercel can get a real project shipped by Friday, and that's not a knock against them. The harder question is what you reach for once the thing has to keep running, unsupervised, for years.
Most projects start the same way: a deadline, an idea worth testing, and no appetite to spend the first two weeks standing up infrastructure. That’s exactly the moment Supabase, Vercel, Neon, and their peers earn their keep. Auth, a database, a deploy pipeline, a CDN: what used to take a sprint now takes an afternoon, and the project is in front of real users while the idea is still alive enough to learn from.
We use these tools. They’re often the right call, full stop, and pretending otherwise would just be a different flavor of dogma.
The real question is which stage you’re building for
A prototype, a pilot, something you’re genuinely not sure will exist in six months: optimize for speed. Get it running, get it in front of someone, find out whether it’s worth the next six months before you spend them. A managed platform is the right tool for exactly this job, and it’s not a compromise to use one.
A system that’s going to run for years, that a client will own and operate long after we’re gone, that has to survive a decade of “who set this up and why”: that calls for something else. Not what’s newest, and not what’s fastest to bootstrap either. What’s still standing, still documented, and still genuinely theirs, ten years on.
What changes once a system has to last
A managed platform bundles a lot of good defaults behind one login and one bill. That’s exactly what makes it fast to start with, and exactly what makes it a single point of dependency. If the platform changes its pricing, gets acquired, deprecates something you rely on, or just stops being the right fit, untangling a live production system from it is real work, the multi-week kind, and it tends to surface at the worst possible time.
Dan McKinley put the underlying trade-off plainly in Choose Boring Technology, the essay that’s shaped how a lot of engineers think about exactly this decision: “It is basically always the case that the long-term costs of keeping a system working reliably vastly exceed any inconveniences you encounter while building it.” That’s the whole argument for picking the boring, proven thing once a system has to last, in one sentence.
Proven primitives don’t remove that risk so much as spread it across infrastructure that’s commodity by design. S3 behaves like S3 whether you’re on AWS today or moving off it next year. Postgres is Postgres whether it’s RDS, a managed instance somewhere else, or a box the client’s own engineer runs. The pieces are plain enough, and standard enough, that replacing any one of them is an afternoon’s work, not a rewrite.
That’s the actual fight, and it was never “boring versus exciting.” It’s whether the system stays genuinely the client’s, in practice, for as long as they need it to.
What’s actually worth picking carefully
We used to put the model provider on this list. It doesn’t belong there anymore. Routers like OpenRouter turned “which model” into something close to a config value, swap providers without rewriting application code. That’s an easy call now, and spending real attention on it just pulls focus from the calls that are genuinely hard to undo:
- The system of record. Whatever owns the canonical data, the schema, the source of truth, is the hardest thing to migrate once a system is live and people trust what it says.
- The prompting approach. This is where most of the actual product quality lives, and it’s tightly coupled to how the rest of the system is built around it.
- The validation layer. Whatever sits between what the model outputs and your system of record has to be right, because nothing downstream will catch it if it isn’t.
The point
Speed and durability aren’t in tension; they just answer different questions. “What gets this in front of someone by Friday” and “what’s still running, unsupervised, in five years” can both be the right question, depending on what you’re actually building. The mistake isn’t picking the managed platform or the proven primitive. It’s picking either one out of habit, instead of asking which stage the thing in front of you is actually at.