// Choose well-understood, battle-tested infrastructure. Save your novelty for the product surface — the place where users actually notice it.
Every founder I talk to wants to build their product on something new. The new database. The new orchestrator. The new edge runtime that benchmarked 30% better in someone's blog post. The argument is always the same: we're building something different, so we need a different stack.
That's almost never true. The thing you're building is probably different. The stack underneath it is almost certainly not.
Where novelty actually pays
Novelty in infrastructure has a brutal cost curve. The first six months feel cheap — the README is friendly, the benchmarks look great, the Discord is enthusiastic. Then you hit an edge case nobody else has hit yet, and you discover that the on-call rotation for this database is you, at 2 a.m., reading a Rust stack trace.
The math on this is straightforward. Boring infrastructure has been operated by tens of thousands of teams. Every weird failure mode has been catalogued in someone else's postmortem. Every operator-error footgun has a Stack Overflow answer. You inherit a hundred thousand person-hours of operational experience by choosing Postgres over the cool new thing.
The novelty that pays is product novelty — the work your users actually notice. If your competitive moat is "we picked the more interesting database," your moat is a footnote in a blog post nobody read.
The actual rule
Use Postgres. Use S3. Use Kafka if you genuinely need a log, Redis if you genuinely need a cache, Kubernetes if you've outgrown a single VM and not a moment before. Pick the technology your team's third-best engineer can debug at 3 a.m. with a glass of water and a search engine.
Save the novelty for the product. That's the part the customer is paying for.
When boring isn't an option
There are real exceptions. If your product fundamentally cannot exist on boring infrastructure — a real-time analytics product that needs columnar storage, a vector-search engine, a financial system that needs strict serializability across regions — then you take on the operational burden with eyes open, write the runbook before you write the feature, and budget for the on-call.
But check, honestly, whether you're in the exception. Most teams aren't. Most teams have a perfectly normal CRUD product and a desire to feel sophisticated, and those two things are not the same.