Our technologies
Our technology stack, chosen for the long term
Every tool here is mature, widely adopted and easy to hire against. We pick for your ten-year maintenance cost, not for what is interesting to us this quarter.
- Full stackWeb, mobile, cloud and data
- AWSCertified & accredited
- HireableNo exotic lock-in
Core stack
What most of our projects are built on
The full list
Everything our engineers work in
Grouped by what it is for, and every one of them links to what we actually do with it. The list grows as projects call for it, so if something you depend on is missing, ask. This is what we use most, not the limit of what we know.
Backend & APIs
Cloud platforms
Infrastructure & orchestration
Testing & QA
Delivery & collaboration
AI & machine learning
Plus the current generation of LLM provider APIs.
How we choose
The stack is a hiring decision as much as a technical one
The most expensive architecture is one only its authors understand. So the test we apply to any technology choice is whether you could hire someone in your own market to maintain it after we are gone.
That rules out a lot of genuinely interesting tools, and it is the right trade. Mature ecosystems have answered the hard questions already: the security advisories, the upgrade paths, the Stack Overflow answer at 2am.
Where a project genuinely needs something specialised, we will make the case explicitly and write down what it commits you to, rather than letting it arrive quietly in a pull request.
Common questions
Questions about our stack
Do you work with our existing technology?
Usually. Most engagements involve inheriting something, and the list above is what we reach for on greenfield work rather than a restriction on what we will touch. Tell us your stack and we will be straight about our depth in it.
Why not the newest framework?
Because you will live with it for years and we will not. New tools carry unknown upgrade paths, thin security track records and a small hiring pool. We adopt things once the ecosystem has absorbed the sharp edges.
Can you do a technology audit before we commit to anything?
Yes, and it is a common first engagement, particularly where a team has inherited a system nobody fully understands. You get a written assessment of dependency health, risk and upgrade cost, and it is yours regardless of what you do next.
Which cloud should we be on?
We are deepest on AWS and hold AWS certification and partner accreditation, so that is where we add the most value fastest. If you are already committed to Azure or GCP, that is usually the right constraint to keep.
Wondering if we know your stack?
Ask directly. You will get an honest answer about our depth in it, including where it is shallow.