Technology
What we build on, and the rule we use to choose
A stack list is only useful with the reasoning attached. Here is both — the technologies we work in every week, and the four principles that decide when we reach for one.
Front end
Interfaces that stay fast on the hardware your users actually own.
- React 18Component architecture, hooks, concurrent rendering
- TypeScriptType safety at the boundaries that matter
- ViteBuild tooling and static prerendering
- Tailwind CSSDesign-system-driven styling
- WCAG 2.2 AAAccessibility treated as a requirement, not a retrofit
Back end
Server code chosen for how well it can be operated, not for novelty.
- PHP 8.3Typed, modern PHP — Laravel or clean modular architecture
- Node.jsEvent-driven services and tooling
- PythonData processing, automation and integrations
- GoHigh-throughput services with a small operational footprint
- REST & GraphQLVersioned, documented, contract-tested
Cloud & platform
Infrastructure described in code so an environment can be rebuilt, not remembered.
- Amazon Web ServicesECS, RDS, S3, CloudFront
- Microsoft AzureApp Service, AKS, Azure SQL, Entra ID
- KubernetesWhere the workload genuinely justifies it
- TerraformInfrastructure as code with reviewed changes
- DockerIdentical images from a developer laptop to production
Data & storage
A schema you can reason about beats a document store you cannot query.
- MySQL 8Transactional workloads, InnoDB tuning
- PostgreSQLComplex queries, JSONB, partitioning
- RedisCaching, queues and rate limiting
- ElasticsearchSearch and log aggregation
- Backup & restore drillsA backup nobody has restored is a hypothesis
Selection principles
Four rules that decide the stack
These are the arguments we will make in a technology discussion, so you may as well have them in advance.
Boring where it counts
The database, the deployment target and the language a maintainer will inherit are chosen for how well they are documented and how easily they are hired for — not for how interesting they are to us.
One less moving part
Every dependency is a thing to patch, monitor and eventually migrate off. A queue, a cache or a service mesh has to earn its place against the cost of operating it for five years.
Reproducible, not remembered
Infrastructure is described in code and environments are rebuilt from that description. If the only copy of how a server was configured is in someone’s memory, it is not configured — it is a rumour.
Decisions written down
Each significant choice gets an architecture decision record: the context, the options considered and why the rejected ones were rejected. The next engineer inherits the reasoning, not just the result.
Security posture, stated accurately
Our engineering controls — code review, dependency scanning, least-privilege access, encrypted transport and at-rest storage, and a documented incident procedure — are modelled on ISO/IEC 27001 Annex A and the OWASP ASVS. We are not certified against either standard and will never imply that we are. If your procurement process requires a certified supplier, tell us at the first contact so nobody wastes a cycle.
Working in something not on this list?
Tell us in the estimate request. If we are not a good fit for your stack, the reply will say so — a supplier who claims every technology is a supplier who has learned none of them properly.