A boring stack, on purpose

Every few months a new framework, database or architecture pattern promises to change how software is built. Some of them do. But for the kind of software most businesses need — operational platforms, SaaS products, internal tools — the most valuable property of a stack is not how new it is. It is how easy it is to understand, run and change for years.

What we optimise for

When we choose technology for a client product, we weigh a few questions above all others:

• Can someone else maintain this? The code will outlive the first team that writes it.
• Is the ecosystem mature? Libraries, documentation, hiring and hosting should be easy.
• Does it reduce the number of moving parts? Fewer languages, fewer services, fewer places for bugs to hide.
• Is it proportionate to the problem? A product with a few thousand users does not need the architecture of a global platform.

Our default, and why

For most web products we start from a small, well-understood core:

1. TypeScript end to end, so the same types describe the database, the API and the interface.
2. React and Next.js for the interface, with server rendering where it helps performance and SEO.
3. PostgreSQL as the relational core — reliable, expressive, and happy with both transactional and analytical workloads at this scale.
4. An ORM with versioned migrations such as Prisma, so schema changes are reviewed like code.
5. Managed hosting or a simple VPS, chosen by the product's needs rather than by fashion.

The best architecture for a new product is usually the simplest one that could reasonably work — with clear seams where it can grow.

Boring doesn't mean careless

A simple stack still needs discipline: typed boundaries, tests around business rules, automated deployments, backups that have actually been restored once, and logging that answers questions when something goes wrong. That is where engineering effort pays off — not in adopting a new tool every quarter.

The costs nobody puts in the estimate

Technology choices are usually justified by what they make possible on day one. Their real cost shows up later, in places that rarely appear in a proposal:

• Onboarding: every additional language, framework or service adds days before a new developer is productive.
• Upgrades: each dependency has its own release cycle, breaking changes and security patches.
• Operations: more services mean more things to monitor, back up and debug at the worst possible moment.
• Hiring: a niche tool can make it hard to find people to maintain the product in three years.

A small, mainstream stack keeps all four of these costs low. It lets the team spend its attention on the part that is genuinely unique to the client — the business logic, the workflow, the data model — instead of on the plumbing around it. That trade is almost always worth making.

When to reach for something else

There are good reasons to go beyond the default: heavy real-time requirements, large-scale data processing, specific integrations, or a team with strong expertise elsewhere. The point is not to forbid new technology. It is to make it earn its place — the same way every feature in a product should.

• Software engineering
• TypeScript
• PostgreSQL
• Architecture