The case for a boring stack by default

Most of the engagements we take on start with a stack that looks like this:

• TypeScript on the frontend
• Next.js or React Native (Expo) for the UI
• Postgres for data, with Supabase smoothing the auth and storage layer
• Stripe for billing
• Vercel for hosting

None of it is exotic. All of it has been production-grade for at least three years. And the choice is deliberate.

The hidden cost of newness

Every novel piece of infrastructure carries a cost the homepage of the project doesn't mention: the cost of being one of the people who has to figure it out from primary sources. Documentation gaps, undocumented edge cases, library compatibility issues, your future self trying to remember how the thing works after six months of not touching it. For a project with deadlines and other people's money on the line, that cost adds up faster than the marginal benefit of being on the bleeding edge.

The corollary: when you pick the boring stack, you get to spend your novelty budget where it matters. The product itself.

When to break the rule

There are exceptions. Three patterns we think hold up:

• **The product *is* the new thing.** If you're building an AI-native product, you can't run away from Anthropic or OpenAI SDKs — those are the product surface. Use them. But still ship the auth, payments, and CRUD on the boring stack.
• The team has demonstrated expertise. If three of your four engineers have shipped production Rust services, Rust isn't novel for that team. Boring is contextual.
• The boring option is actually the worse one. Sometimes the established option is on its last legs (jQuery in 2018, Sapper in 2022). Migrating off boring-but-dead is a cost, but it's a smaller cost than building atop it.

What this looks like in practice

When we scope an engagement, we ask: what part of this is going to be novel? What does the team *have* to learn? Then we look for the smallest set of tools that lets us do that one novel thing well, with everything else being a known quantity.

The result usually surprises clients. They expect a consulting firm to push the latest framework or to over-engineer the architecture diagram. We push the opposite. Less novel infrastructure means more time spent on the product, and more time spent on the product is almost always the right answer.

There's a longer version of this argument in Dan McKinley's Choose Boring Technology, which we recommend to every client at the start of an engagement. Our take is the same in spirit — applied to web and mobile app development in 2026.