Most early-stage stacks are interesting in the wrong places. The unique value of the product gets the boring solid technology — a CRUD API, a simple Postgres, a standard web framework. Meanwhile auth, payments, observability, and secrets are stitched together from whatever was on Hacker News last week. Six months later, the interesting choices in the load-bearing layer are the things that wake the team up at 3am.
We tell every founder the same thing. Make boring choices for the parts that load-bear. Save your invention budget for the surfaces customers actually touch.
What I mean by load-bearing
The parts that, if they fail, take the whole product down or expose you to a kind of risk you can't easily reverse. Authentication. Authorisation. Payments. Observability. Secrets management. Backups. The boring choices are usually: a managed identity provider, a managed payment processor, a managed log-and-metric platform, a key-management service from your cloud, and an automated backup with a real restore drill.
The interesting choices are: writing your own JWT verification, rolling your own MFA flow, building your own logging pipeline, hand-managing secrets in environment variables. We've seen all of these become incidents. None of them were good ideas.
What I mean by boring
Boring means: well-documented, widely deployed, fits in your team's existing skill set, fixable by people you can hire next year, and unlikely to be deprecated this decade. Not necessarily older — just stable, predictable, and supported.
Postgres is boring. So is Auth0, Clerk, Stripe, Datadog, AWS Secrets Manager. None of those will get you a tweet of admiration from a CTO friend. All of them will mean your team can sleep through Saturday.
Where this breaks
Two places, in our experience. First, when the founder picks the technology to attract a particular kind of engineer. "We use this because it lets us hire from this community." If the community is small or shrinking, you're hiring against the wrong index. Second, when the load-bearing layer becomes the place where the team feels they can be creative — because everything else is locked down by product decisions. That's a culture issue, not a tech issue, and it shows up in the runbook.
The trade-off
You will sometimes pay vendor money for a feature you could build. That's the right trade for the load-bearing layer. The thing you save isn't engineering hours — it's the on-call cost of running it for the next five years, and the hiring cost of finding people who can.
Be inventive on the part of the product your customer touches. Be boring everywhere else. The customer will never notice, and that is the whole point.