Technologies
Grouped by the decision each one belongs to rather than stacked into a logo wall, and published without a count — the number of technologies on a supplier’s website measures the website.
Filled marker = what we reach for first
We default to typed languages on anything expected to outlive the team that wrote it. The rest of this list is what we inherit and maintain.
Rendering strategy is an architectural decision, not a preference. We pick it from how the content changes and who has to edit it.
Cross-platform where the interface is mostly forms and lists; native where the value is in the camera, the sensors, or the background behaviour.
Every environment is described in code, so the one that broke can be rebuilt rather than remembered.
Relational until something proves it should not be. Most of the document stores we are asked to adopt are solving a schema problem with a filing problem.
Models go in behind an evaluation harness. A system nobody can measure is not intelligent, it is unaccountable.
Instrumentation ships before optimisation, which is the only reason we can attribute an improvement instead of asserting one.
Design files are a working artefact, not a deliverable. What ships is the component, and the two stay in the same review.
Capabilities
A stack list says what we can type. These say what we will do with it — and each one names the service it is delivered inside, because the service taxonomy is four deep and stays that way.
Retrieval over your own documents, classification and extraction on the workflows currently done by hand, and agents that are allowed to act only where a wrong answer is recoverable. Every model ships behind an evaluation set, so a regression is caught by the pipeline rather than by a customer.
Re-platforming and refactoring systems that were built for a rack. We move the parts that get cheaper or safer in the cloud and leave the rest, because a lift-and-shift of an application that was never designed to scale horizontally buys a bigger bill and the same bottleneck.
Pipelines, environments and release governance, described in code. The goal is a deployment that is boring enough to happen on a Friday, and an environment that can be rebuilt from the repository rather than from the memory of whoever set it up.
Automated coverage where the cost of a defect is highest, load testing against a number someone has committed to, and accessibility checked in the pipeline rather than audited at the end. We will tell you which parts of a suite are worth keeping and which are only slowing the build down.
Threat modelling on the design, dependency and secret scanning in the pipeline, and remediation work on the findings a penetration test comes back with. We do not sell the penetration test itself: an independent party should run it, and we will work to their report.
The layer between the systems you keep — public and partner APIs, webhooks, single sign-on, and the middleware that lets a bought product and a built one agree on what a customer is. Versioned, documented, and built to survive the upgrades of everything either side of it.
Ingestion, fleet state and the operator interface for hardware that reports from the field. Most of the difficulty is not the device: it is a network that drops, a clock that drifts, and a payload schema that has to change without bricking what is already deployed.
Discovery, a riskiest-assumption build, and then iterations that each end with something deployed. Where a proof of concept is the right first step we scope it as one, with an explicit decision point at the end rather than a slide deck and an invoice.
Interface and interaction design delivered as components rather than as flat files, with accessibility treated as a requirement at AA. The design system and the code review are the same review, which is what stops a library drifting from the product it describes.
Engineers who join your standups, your repository and your on-call rota, under your technical direction. No subcontracting: everyone on the engagement is ours, and you meet each of them before they start.
How to check this page
Every case study on this site prints the architecture of that engagement — the stack, the decisions taken, and the reasoning behind each one. If something here matters to you, read the study that used it, and ask us about the parts that are not in one.
Existing platform, existing constraints, existing team. Send us the shape of it and a senior engineer will tell you what we would keep and what we would change.
