This is the long version of what we staff. How the disciplines group together, how a stack actually gets chosen, what every engagement carries regardless of technology, and the squad shapes we see repeatedly. Each discipline also has its own guide with stack lists, comparisons and honest trade-offs.
Depth we hold ourselves, not a list assembled from a recruiter's network.
Senior by default. Juniors only where you explicitly ask for them.
Including interviews, contracting and onboarding into your codebase.
Clients almost never need one discipline in isolation. They need a surface, the platform under it, the data behind it, and the assurance around it. Grouping them this way makes it easier to see which conversation you are actually having.
Product surfaces
Web, mobile and the design work that holds them together. These disciplines decide whether the product feels considered or merely functional, and they are the ones users judge within the first thirty seconds. We staff them with engineers who can hold a design system, a performance budget and an accessibility standard in their head at the same time.
When you need it
You are shipping something people log into daily, your interface has grown faster than its conventions, or the product tests well on paper and poorly in the hand.
Platform & infrastructure
APIs, services, pipelines, environments and the operational discipline around them. This is where scaling problems, cloud bills and on-call fatigue originate, and where good engineering is least visible and most valuable. We put people here who have carried a pager, not only drawn an architecture diagram.
When you need it
Deploys are frightening, your cloud spend has stopped tracking usage, incidents repeat, or a monolith has become the reason every roadmap item takes a quarter.
Data & intelligence
Data platforms, warehouses, model work and applied AI. Most organisations do not have a modelling problem — they have a data-quality and plumbing problem wearing a modelling costume. We start by making the numbers trustworthy, then build on top of them.
When you need it
Two dashboards disagree, reporting is a manual monthly ritual, or an AI feature is on the roadmap and nobody can say where its training or retrieval data would come from.
Quality, security & delivery
Test automation, application security, compliance evidence and the delivery leadership that keeps a roadmap honest. These are the first roles cut under pressure and the reason releases later slow to a crawl. We treat them as structural, not optional.
When you need it
Regression testing is manual, a security questionnaire is blocking a deal, an audit is approaching, or engineering output no longer resembles what the roadmap promised.
Each guide covers what we build, the stack we use, an honest comparison of the options, the advantages and the trade-offs, and the people we put on it.
Frontend
React, Next.js, Vue, TypeScript. Design systems that scale.
Read the guideMobile
Native Swift & Kotlin, React Native, Flutter. Store-ready.
Read the guideBackend
Node, Go, Python, Java. Event-driven, distributed, resilient.
Read the guideCloud
AWS, GCP, Azure. Kubernetes, Terraform, CI/CD, observability.
Read the guideData & AI
Applied ML, LLM pipelines, inference infra, evals, RAG.
Read the guideData
Warehouses, streaming, ELT, analytics-ready models.
Read the guideQuality
E2E, load, security testing. Playwright, Cypress, k6.
Read the guideAutomation
Workflow automation, internal platforms, integrations.
Read the guideSecurity
Threat modelling, hardening and the technical build-out behind SOC 2, HIPAA and GDPR.
Read the guideProduct
Product design, prototyping, accessibility, motion.
Read the guideDelivery
Product managers, tech leads, delivery managers.
Read the guideEmerging
Smart contracts, wallets, on-chain infra when it fits.
Read the guideEmbedded
Firmware, RTOS, device connectivity and edge software.
Read the guideTechnology choices are trade-offs, not verdicts. Find the row that matches what you are building; the last column is the part most proposals leave out.
| What you are building | Where we usually start | Why | What it costs you |
|---|---|---|---|
| A public, content-heavy product | Next.js or TanStack Start on TypeScript, with edge caching | Server rendering carries the SEO and first-paint burden, and both frameworks give the team typed routing instead of hand-rolled conventions. | A server runtime to operate, and framework upgrades you cannot indefinitely defer. |
| An authenticated dashboard behind a login | A Vite SPA with TanStack Query | No crawler to satisfy, so you trade SSR complexity for the simplest possible mental model and the fastest iteration loop. | Slower first paint on cold loads, and no useful search presence for the app itself. |
| One app across iOS and Android with modest native needs | React Native or Flutter | One team, one codebase and near-parity on the surfaces most products use. Release cadence stops depending on two separate specialisms. | A dependency layer between you and each new OS release, and native modules whenever you leave the well-trodden path. |
| An app whose whole value is a native capability | Swift and Kotlin, written natively | Camera, audio, background processing, offline sync and accessibility all behave the way the platform intends, with no bridge to debug. | Two codebases, two release trains and roughly double the mobile headcount. |
| A new backend with an uncertain domain | A modular monolith in TypeScript, Go or Python | Service boundaries drawn before you understand the domain are the most expensive mistake in the category. A modular monolith lets boundaries emerge. | You must actually enforce the module boundaries, or you inherit a big ball of mud with extra folders. |
| A system with genuinely independent scaling profiles | Targeted services with an explicit contract layer | Isolating the two or three components with different load and failure characteristics buys real resilience without distributing the whole system. | Distributed tracing, contract testing and deployment orchestration become permanent operating costs. |
| Analytics that several teams depend on | A warehouse-first stack — managed ingestion, dbt, a columnar warehouse | Transformations live in version control and are testable, so numbers become reproducible rather than argued about. | Warehouse spend needs active governance, and someone has to own the semantic layer. |
| An AI feature on an existing product | Retrieval over hosted models first, fine-tuning only when measured to be necessary | Most perceived model problems are retrieval and evaluation problems. Solving those first is faster, cheaper and reversible. | Per-token cost and vendor dependency, both of which need monitoring from the first week. |
| A regulated product with audit exposure | Boring, well-supported technology with strong compliance tooling | Auditors reward legibility. Mainstream stacks come with mature evidence, scanning and access-control ecosystems. | Less freedom to adopt whatever the ecosystem is excited about this year. |
None of this is a house style you have to accept. If your team already has conviction about a stack, that conviction is usually worth more than our preference — a team shipping confidently in a slightly wrong framework outperforms a team learning a slightly better one.
These are not upsells or a maturity roadmap. They are the baseline our engineers work to on the first day, in your repositories, under your conventions.
Static typing across the boundary, not just inside it. Shared contracts between client and server so refactors surface at compile time rather than in production.
Unit coverage where logic is dense, integration coverage across boundaries, and end-to-end coverage on the handful of journeys that lose you money when they break.
Lint, typecheck, test and build on every pull request. If a repository has no pipeline when we arrive, standing one up is part of the first fortnight.
Every change is reviewed by a second engineer. Our people are expected to review your team's work as well, and to have their own reviewed by you.
Architecture decision records for consequential choices, runbooks for anything with an on-call implication, and a README that a new joiner can actually follow.
Dependency scanning, secret management, least-privilege access and no production credentials on laptops. Applies to a two-week specialist as much as a two-year squad.
Structured logs, traces and meaningful alerts added while the system is small, so the first incident is diagnosed rather than guessed at.
Knowledge transfer is a continuous artefact, not an exit meeting. If we leave, the material to run the system without us already exists.
The disciplines are the what. The process is the how — documented in full on the approach page, summarised here.
You describe the problem and the constraint. We recommend the disciplines and the smallest model that solves it.
Within about a week: named engineers, re-screened against your stack and domain, with our interview notes.
You decide. We schedule, prepare and debrief, and we never present someone we would not hire ourselves.
Contracting, access and onboarding, with a written thirty-day ramp plan per person and a first meaningful pull request inside two weeks.
Composed against the work, never against a template — but these are the shapes we return to, including the fractional roles most plans forget to budget for.
| Product type | Disciplines involved | Typical shape | What people underestimate |
|---|---|---|---|
| Consumer mobile product | Mobile, backend, design, QA | 2 mobile, 1 backend, 1 designer, 0.5 QA automation | Release engineering and store compliance are underestimated — budget for them from the first sprint. |
| B2B SaaS platform | Web, backend, DevOps, QA | 2 web, 2 backend, 1 DevOps, 1 QA automation | Tenancy, permissions and audit logging are architectural, not features you add later. |
| Internal tooling and automation | Automation, backend, design | 1 automation, 1 backend, 0.5 designer | The win is usually process clarity before software. Expect the first two weeks to be mapping, not building. |
| Data platform and reporting | Data engineering, backend, delivery lead | 2 data, 1 backend, 0.5 delivery lead | Source-system access is the critical path. It almost always takes longer than the engineering. |
| AI-enabled product feature | ML and AI, backend, data, QA | 1 ML, 1 backend, 1 data, 0.5 QA | Evaluation harness first. Without one, nobody can tell whether a change improved the feature. |
| Platform modernisation | DevOps, backend, security, delivery lead | 1 DevOps, 2 backend, 0.5 security, 0.5 delivery lead | Incremental strangler migration, never a big-bang rewrite. Value has to land each quarter. |
| Compliance and audit readiness | Security, DevOps, QA | 1 security, 1 DevOps, 0.5 QA | Evidence collection is the bulk of the work. The controls themselves are often already half in place. |
Including the ones where the honest answer is not the flattering one.
No. You own the technology decisions on your own product. Where we have a view we will put it in writing with the reasoning, and if you choose differently we staff the stack you chose. The only thing we will not do is quietly rewrite a working system into our preferences.
Legacy work is a large share of what we do. We staff Java, .NET Framework, PHP, AngularJS, Rails and on-premise estates. The engineers who genuinely enjoy this work are rarer and command a premium, so it is worth telling us early rather than at contract stage.
Yes. A single senior specialist — a DevOps engineer, a security engineer, a QA automation lead — is a common first engagement. Below roughly half a full-time equivalent the coordination overhead outweighs the benefit, so that is where we advise against it.
A squad is composed against the work, not against a template. The coverage table on this page shows shapes we see repeatedly. Fractional allocation is normal for design, security and delivery leadership, where a half or quarter of a person is genuinely the right answer.
You do, from the first commit, assigned in the contract and covering everything produced during the engagement. Work happens in your repositories, on your infrastructure, under your licences.
Say so in the brief. The twelve on this page are where we hold depth on the bench. Beyond them we can often source through our network within two to three weeks, and we will tell you plainly when we cannot rather than sending an approximate fit.
Each guide is reviewed against what our engineers are actually shipping, not against release notes. If a technology appears on a stack list, someone on the bench has used it in production within the last year.
Yes, and it is the default. Your repositories, your ticketing, your ceremonies, your review conventions. We do not import a parallel process, and we do not ask your team to adopt ours.
Typically one week from brief to shortlist and three to four weeks to a first meaningful pull request, including interviews, contracting and onboarding. Rarer specialisms — deep security, particular ML domains, unusual legacy stacks — can add a week or two at the sourcing stage.
Regularly. The first two weeks are a read-only assessment: architecture, test coverage, dependency risk, operational maturity. You get that written up whatever happens next, including if the conclusion is that you need less help than you expected.
Six short steps in the brief. You get a written read-back, a recommended squad shape with reasoning, an indicative cost range and a realistic start date — within one business day.