Technologies

What we build on, and why

A stack list is easy. The useful part is the reasoning, because you are the one who keeps the code and has to hire someone to maintain it.

Technical stack

Chosen so you can hire for it

We pick mainstream, well-supported technology on purpose. The test is not what is interesting to write — it is whether you can recruit someone to maintain it in three years.

Mobile Development

Native

Swift
Objective-C
Kotlin

Cross-platform

Flutter
React Native
Xamarin

Web Development

Frontend

React
Angular
Vue
TypeScript
JavaScript

Backend

Node.js
Python
Java
PHP

Data & Storage

Databases

PostgreSQL
MySQL
MongoDB

Also working with

Frameworks

Next.js
Nest.js
Laravel
Django
FastAPI
Svelte
Astro
Tailwind CSS

AI & data

Mistral
Claude
OpenAI
Llama
LangChain
pgvector
Qdrant
Pandas

Cloud & DevOps

AWS
Azure
Google Cloud
Docker
Kubernetes
Terraform
GitHub Actions
Cloudflare
Redis
LiteSpeed

Platforms & APIs

WordPress
Shopify
WooCommerce
GraphQL
REST
Stripe
Firebase
Supabase
Prisma

The reasoning

Front end

Next.js with React and TypeScript

Server rendering by default, which matters more than it used to: AI crawlers such as GPTBot, ClaudeBot and PerplexityBot largely do not execute JavaScript, so a client-rendered app is close to invisible to them. TypeScript because a type error caught at build time is free and the same bug found in production is not.

Back end

Node.js, Laravel or Python — chosen per project

Node when the front end is already TypeScript and sharing types is worth real money. Laravel when the team maintaining it is a PHP team, which in the UK mid-market is often the case. Python when the work is data or model heavy. We pick for who maintains it, not for us.

Database

PostgreSQL, or MySQL where the host requires it

Postgres for anything with interesting data shapes, JSON columns or vector search via pgvector. MySQL where existing infrastructure or shared hosting dictates it — which is common and perfectly workable.

Mobile

Flutter or React Native, native where justified

Cross-platform saves roughly 30–40% and suits most business apps. Native Swift or Kotlin when the app leans hard on the device — sustained camera work, background location, complex continuous animation.

Mistral, Claude and open-weight models

Benchmarked against your own evaluation set rather than a vendor leaderboard. Self-hosting an open model becomes worthwhile at steady high volume or where data cannot leave your infrastructure — that is a calculation, not a preference.

Infrastructure

Docker, AWS or your existing host

Containerised so it runs the same locally and in production. We are happy deploying to whatever you already pay for rather than migrating you to something that suits us.

Stack questions

One question decides most of it: who maintains this in three years, and can you hire them? A stack that is elegant but unhireable is a liability you inherit. We also weigh what you already run — introducing a second language into a small team is a real cost.

Yes, and usually we should. Rewriting a working system into our preferred tools is rarely in your interest. We adopt your conventions, branching model and review process. Where we genuinely think a technology choice is holding you back, we will make the case with numbers rather than preferences.

When it fits, yes — and it fits more often than developers like to admit. If your team publishes frequently and needs full editorial control without a developer, a hardened WordPress build is the pragmatic answer. What we will not do is stack two page builders and twenty plugins on it and call it a website.

Because you keep the code and we do not. Boring, well-supported technology with a large hiring pool is a feature of the deliverable, not a lack of ambition. We will use something newer where it solves a real problem, and we will tell you what the trade-off is.