Technology Stack

The technologies this team works in, grouped by where they sit in a stack. It is a list of what we can pick up and be useful in from the first week, not a claim that every one of them is the right answer for you.

How a stack actually gets chosen

Three things decide it, in this order. What you already run, because a rewrite you did not ask for is the most expensive thing an agency can talk you into. Who will maintain it after we leave, because a stack your team cannot hire for is a liability no matter how good it is. And what the project genuinely requires, which is usually less exotic than it first appears.

What does not decide it is what is new. A technology that arrived last year has no long-term support story and no pool of experienced developers yet. That is fine for an experiment and a real risk for a system you intend to run for a decade.

If you already have a stack

We work in it. Most of the work that comes to us is on a system that already exists, and the useful version of that engagement is one where we learn your codebase rather than propose replacing it. Where something genuinely does need replacing, we say why, what it would cost, and what happens if you leave it alone instead.

Choosing between two options

The comparisons that come up most often, hosted platform against one you own, native against cross-platform mobile, a headless front end against a traditional one, are covered on the relevant capability and solution pages, where the answer can be tied to a real situation instead of argued in the abstract.