Choosing a Tech Stack

Whose problem is the stack?

Yours, in the end. We will work with almost anything; you will be maintaining, hiring for and extending it for the next five years. So the criteria that matter are yours, not ours.

That single reframing removes most stack arguments. The question is not which technology is best but which one leaves you in the best position in three years.

The criteria we actually weigh

1. Can you hire for it? How many developers in your city or budget bracket know it?
2. Does it fit the problem? Content-heavy, data-heavy and real-time projects genuinely favour different tools.
3. Will it still be maintained in five years? Community size and release history, not enthusiasm.
4. What do you already run? A team that knows one language should probably get another system in it.
5. What does hosting cost and how hard is it to operate?

The best stack for your project is the one you can hire a replacement for in a fortnight, not the one that was most fun to build with.

What we reach for, and when

There is no single answer, and any agency with one answer for every project is telling you about themselves rather than about your problem.

Criteria that sound important and are not

• Raw performance benchmarks. Your bottleneck will be the database and the network, not the language.
• What large technology companies use. Their constraints are not yours by several orders of magnitude.
• Newness. A framework two years old has unknown longevity and a small hiring pool.
• Developer enthusiasm. Real and legitimate, and it should not outrank your ability to hire.

When we push back on a client's choice

Occasionally a client arrives with a stack decision made. We will follow it if there is a reason — an in-house team, an existing system, a compliance constraint. We will argue if the reason is that someone read an article.

The argument we make hardest is against a stack nobody local can maintain. Building something excellent that you cannot hire for is a slow-motion problem that lands about eighteen months after we leave.

Keeping the choice reversible

Whatever the stack, some decisions should stay changeable: keep business logic out of framework-specific corners, keep the database schema clean and portable, keep third-party services behind an interface.

Nobody rewrites a whole system successfully. Everybody replaces parts of one, and the projects where that goes smoothly are the ones where the parts had edges.

Frequently asked questions