The Web Stack We Actually Use in 2025 (And Why We Chose It)

We get asked about tech stack a lot. Usually by clients who've been burned by an agency that picked something exotic, disappeared after go-live, and left them with a codebase nobody in Australia knows how to maintain. So here's exactly what we use and why.

For most web projects: Next.js on the frontend, TypeScript throughout, Postgres for the database, and wherever possible — Vercel for hosting. It's not the most exciting answer, but there's a reason half the web runs on this combination. The ecosystem is massive, the hiring pool is deep, and things mostly just work.

We've shipped projects in plain React, Remix, Astro, and SvelteKit. All have their place. But Next.js wins for most business applications because:

We'd reach for Astro for pure content sites. We'd reach for SvelteKit if performance was the obsession and the team was small. For most things: Next.js.

We don't build in plain JavaScript anymore. The argument against TypeScript used to be that it slows you down. That was true five years ago. The tooling is good enough now that it's faster — you catch entire categories of bugs before they hit staging, and code completion means you spend less time reading documentation.

More importantly: it makes handover to a future team dramatically less painful. When we finish a project, the client isn't left with a maze of undocumented implicit types.

Postgres. Almost always Postgres. We use Supabase when we want managed Postgres with auth and real-time baked in, or PlanetScale when the scale justifies it. We've worked with MongoDB and the document model has its uses — mainly when the schema genuinely has no shape — but in practice most business data has shape, and you're better off admitting that upfront.

For caching, Redis. For full-text search on anything moderately complex, we'll stand up a small OpenSearch instance rather than reaching for workarounds inside Postgres. The temptation to keep everything in one database is understandable but it's usually worth resisting once search quality starts mattering.

We're less enthusiastic about a few things we used to reach for by default:

The best stack for your project is the one your team can ship confidently, debug at 11pm when something breaks, and hand off to someone else in 12 months. Technology that makes you feel clever but creates a maintenance cliff is a liability, not an asset. We try to build boring software that works.