How we work

16 industries, five architectures

We list sixteen industries on our site. That raises a fair question from anyone evaluating our team: how can one team credibly claim to understand defence firmware, hospital software, ad exchanges and ERP modernisation? The honest answer is that we don't treat them as sixteen problems. We treat them as five.

Industry is a buyer's taxonomy, not an engineering one

Industry labels are useful for exactly one thing: helping a buyer find themselves on a website. They are close to useless for predicting what is wrong with a delivery pipeline.

Two companies filed under "fintech" can have opposite problems. One runs a real-time authorisation path where an extra 40ms costs merchant contracts. The other is a lending platform whose engineering is fine and whose auditor is the bottleneck. Nothing about the word "fintech" tells you which one you're looking at. Meanwhile that lending platform and a hospital EHR vendor two industries away have almost the same problem, the same evidence gap, and the same fix.

So we stopped organising our thinking around sectors and started organising it around the thing that actually shapes a pipeline: what constrains the release.

The pipeline is broadly the same everywhere. What changes is the definition of "safe to ship," and what it costs you to be wrong.

The part that genuinely doesn't change

Before the differences, it's worth being blunt about how much is shared. Across every engagement we've run, roughly eighty percent of the platform is the same set of components solving the same set of problems:

Source control with a branching model the team can actually follow under pressure
Build infrastructure that is fast, cached, and produces the same artefact twice
An immutable, versioned artefact registry, so "what is in production" has a precise answer
Infrastructure as code, with environments that resemble each other
Secrets that live somewhere other than a CI variable someone pasted in 2023
Observability that answers "is this release healthy" rather than just "is the box up"
Access control, change traceability, and an incident process people trust enough to use

The failure modes repeat just as reliably. A release checklist in a wiki that one person truly understands. A staging environment nobody believes. A test suite with enough flaky cases that red means "retry." A security review bolted on at the end of the quarter. Those show up in defence firmware and in ad tech with equal frequency, and they are fixed the same way in both.

This is why a generalist platform team is not a weakness. The substrate is common, and building it well is a craft in its own right.

The part that does change, and why it matters

The remaining twenty percent is where engagements succeed or fail, and it is driven by four questions. The answers are what separate the archetypes:

What has to be true before this ships? The gate.
How do we prove it was true, six months later? The evidence.
What does "undo" actually cost? The rollback.
What does a test environment physically have to be? The harness.

Ask those four questions of any company and you land in one of five archetypes. Here they are.

Archetype 1

Hardware-bound and physically safety-critical

Embedded Systems & Defence · Automotive & Mobility · Telco & Networking · Energy & Utilities

Software controls physical equipment. A bad release bricks a device, voids a warranty, or hurts someone. Rollback may require a truck.

Builds here are slow and cross-compiled, often measured in hours rather than minutes. The test environment isn't a container: it's a bench of real silicon that has to be reserved, flashed, power-cycled and shared across teams. And the deployment target may be a device sitting on a wind turbine with intermittent connectivity, running firmware nobody can physically reach.

What changes in the pipeline

Deterministic, reproducible OS images (Yocto recipes, Buildroot, PREEMPT_RT kernels), so the binary under test is the binary in the field
Software-in-the-loop stages that catch most regressions cheaply, before anything touches a hardware-in-the-loop bench
HIL benches treated as scheduled CI resources with automated reservation, flashing and recovery, instead of a bench someone books on Slack
Staged OTA delivery with A/B partitions, watchdog-triggered fallback, and cohort rollout rather than fleet-wide release
Traceability that survives an audit: requirement to test case to signed binary

The standards we work inside

DO-178C for aerospace, ISO 26262 and ASIL decomposition for automotive, IEC 61508 for industrial functional safety, NERC CIP for energy.

Reference points we work from: Frank Vasquez and Chris Simmonds, Mastering Embedded Linux Development, 4th Edition (Packt, 2025), covering Linux 6.6 and Yocto 5.0; the Eclipse Foundation Software Defined Vehicle working group; LF Energy's CI whitepapers.

Archetype 2

Regulated data and audit-first delivery

Healthcare & MedTech · Fintech & Banking · GovTech & Public Sector · EdTech

Shipping fast means nothing if it violates a statutory control. Separation of duties, immutable audit trails and provable data access are not negotiable.

The bottleneck in these companies is rarely engineering capability. It is the manual control layer wrapped around engineering: change advisory boards, screenshot evidence folders, a release manager who signs a form, and a two-week scramble every time an auditor asks what changed. Teams end up batching releases to reduce paperwork, which makes each release larger and riskier, which produces more paperwork.

The way out is to stop treating compliance as a review and start treating it as code. When the control is a policy gate in the pipeline, the evidence is a by-product of deploying rather than a project that follows it.

What changes in the pipeline

Policy-as-code gates replacing manual change review, with exceptions recorded rather than negotiated
Cryptographic provenance on every release: SBOM generation, SLSA-aligned build attestation, artefact signing with Sigstore or Cosign
Automated evidence capture (approvals, test results, scan results, deployment records) assembled into an audit package on every deploy
Separation of duties enforced by the platform rather than by convention, so a developer cannot promote their own build without breaking a rule that leaves a trace
Data controls in lower environments: masked or synthetic datasets, and proof that production data never leaves its boundary

The standards we work inside

21 CFR Part 11 and IEC 62304 for medical device software, PCI-DSS v4.0 for payments, FedRAMP and SOC 2 Type II for government and enterprise, FERPA for education. AAMI TIR45 remains the clearest guidance available on running agile and DevOps practices inside a regulated medical software process.

Reference points we work from: Helen Beal, Bill Bensing et al., Investments Unlimited, still the best single text on automating governance into a pipeline.

Archetype 3

Ultra-scale, low-latency, high-availability

AdTech & Publishing · Gaming & Media Streaming · Ecommerce & Retail Tech · Travel & Hospitality

Milliseconds are revenue and peak traffic is the whole year's margin. An outage during Black Friday, a fare sale or a live event is measured in millions.

These businesses tend to have strong engineering and a structural fear of deploying. The result is a change freeze from November to January, which concentrates six weeks of untested change into one January release, the single riskiest thing they do all year.

The fix is not more caution. It is making a release small, observable and instantly reversible, so that deploying during peak is less frightening than not deploying.

What changes in the pipeline

Progressive delivery with automated, metric-driven rollback (Argo Rollouts or Flagger watching real SLIs, not a human watching a dashboard)
Feature flags that decouple deploy from release, so shipping code and exposing behaviour are separate decisions
Zero-downtime schema migrations using expand-and-contract, because the database is where most "we can't roll back" stories actually begin
Consumer-driven contract testing to stop multi-service integration breaks before they reach an environment
Load and soak testing as a pipeline stage with realistic traffic shapes, plus CDN purge and edge configuration treated as versioned deployments
Error budgets driving release policy, so freezes are triggered by reliability data rather than by the calendar

Reference points we work from: Martin Kleppmann and Chris Riccomini, Designing Data-Intensive Applications, 2nd Edition (O'Reilly, 2026); the architecture tracks at QCon and AWS re:Invent, particularly published canary-analysis practice from large streaming and gaming platforms.

Archetype 4

Compute-intensive and non-deterministic

AI, ML & Data Platforms

The code is deterministic. The model and the data are not. A green test suite tells you almost nothing about whether this release is better than the last one.

This is the archetype where conventional CI/CD thinking breaks down hardest. There are three moving artifacts instead of one (code, data, and weights), and only the first is under version control at most companies we meet. Teams can tell you which commit is deployed. Far fewer can tell you which dataset produced the model currently serving traffic.

Add GPUs, and cost becomes a first-class engineering constraint rather than a finance problem. A pipeline that queues badly can burn a month's budget on idle accelerators.

What changes in the pipeline

Versioning across all three artifacts (code, data and models) with DVC, MLflow and a feature store, so any prediction can be traced to what produced it
CI that tests for data drift and model regression against held-out evaluation sets, with promotion gated on evaluation results rather than on unit tests alone
GPU treated as a scarce scheduled resource: fractional allocation in Kubernetes, queueing, and visible cost per training run
Serving pipelines built on vLLM or Triton with shadow deployment, so a new model sees real traffic before it answers to it
Reproducible training environments, because "it scored higher on my machine" is not a release decision

Reference points we work from: Abi Aryan, LLMOps (O'Reilly, 2025); Cathy Chen, Niall Richard Murphy et al., Reliable Machine Learning (O'Reilly); the MLOps Community's ongoing work on CI/CD for LLM serving.

Archetype 5

Developer experience and legacy modernisation

Cloud SaaS & Platforms · Cybersecurity Vendors · Enterprise Internal Systems (ERP, CRM)

Nothing here is unsafe. Everything here is slow. Friction is the product defect, paid for in engineer-months rather than incidents.

The symptoms are familiar: a new hire takes nine days to make a first commit. Four teams have four different ways to deploy. A staging server was configured by hand in 2019 by someone who has left. The cloud bill grew 40% last year and nobody can attribute the increase to a decision.

None of that triggers an outage, which is exactly why it persists. It simply takes a quarter of your engineering capacity, quietly, forever.

What changes in the pipeline

An internal developer platform with real golden paths (Backstage, Port or Kratix) where the paved road is genuinely the easiest route, not a mandate
Self-service environments and service templates, so a new service starts compliant and instrumented instead of being retrofitted later
A service catalogue with real ownership, so "who owns this" has an answer at 2am
Strangler Fig decomposition for monoliths and legacy ERP surfaces, routing traffic away incrementally rather than betting on a rewrite
FinOps signals in the pull request, with cost deltas visible at review time rather than on next month's invoice

Reference points we work from: Matthew Skelton and Manuel Pais, Team Topologies, 2nd Edition (IT Revolution, 2025); the platform engineering track at KubeCon on internal developer platforms.

The five, side by side

Archetype	What must be true before release	What rollback costs	What the test environment is
1. Hardware & safety	The image is safe on real hardware, and traceable to a requirement	OTA recovery at best, a field visit at worst	A hardware-in-the-loop bench with real silicon
2. Regulated & audit-first	The control was enforced, and there is proof that it was	Technically cheap, expensive in reporting and trust	Production-like, with masked or synthetic data
3. Ultra-scale	Behaviour holds at peak load, not average load	Seconds if automated, seven figures if not	Load and soak stages with realistic traffic shapes
4. AI, ML & data	The model performs on data it has never seen	Retraining time and GPU spend	An evaluation harness over held-out datasets
5. DX & modernisation	The change doesn't break anyone else's path to production	Low, which is why the problems go unaddressed	An ephemeral environment per pull request

Read the table by row and the shared 80% disappears from view. That is deliberate: this is only the part that differs.

Most companies are in two archetypes at once

This is the part an industry list can't express, and it's the main reason we work this way.

A medical device company with a cloud companion app is hardware-bound and audit-first, and the two pull against each other constantly. A payments platform running real-time authorisation is audit-first and latency-critical, which is why its change process and its SLOs are usually in open conflict. A diagnostic AI vendor is audit-first and non-deterministic, and has to answer a regulator's question about a model it cannot fully explain. An enterprise retailer running an ERP alongside a storefront is ultra-scale and a modernisation problem in the same building.

Naming both pressures separately, instead of treating the company as one undifferentiated "medtech" or "fintech" engagement, is usually the first genuinely useful thing an outside engineer does. It is also how you avoid the standard consulting failure in this space: applying Archetype 3 practices (canary everything, deploy on Friday) to an Archetype 1 problem where the rollback path runs through a service truck.

Where sector knowledge does matter, and what we don't claim

We should be precise about the limits, because the archetype argument can be stretched too far.

We do not write your clinical decision logic, your trading strategy, your motor control firmware, or your bidding algorithm. We don't interpret your regulator's intent for you, and we won't tell your quality lead what IEC 62304 requires of your specific device class. Those are your domain, and they should stay there.

What we bring is fluency in the constraint rather than the product: enough vocabulary to sit in a room with your QA lead, your security officer or your hardware team and understand what they're protecting, then turn that into a gate, an artefact and a rollback path that runs without a human remembering to run it. Twenty-six years of release engineering across Nokia, Stryker, VeriSign and IP Infusion is largely twenty-six years of that translation work.

The path from commit to production is our domain. What travels down it is yours.

Common questions

Can Stonetusker's team of consultants really serve 16 industries?

Not as sixteen. As five architectures, with eighty percent shared substrate and a constraint model for the rest. We also run a limited number of active clients at a time, which is the other half of the answer. Depth comes from the engagement model, not from headcount.

We're in an industry you don't list. Does that rule us out?

Almost certainly not. The four questions above place you in an archetype regardless of what your sector is called. If a release in your company is constrained by hardware, regulation, scale, non-determinism or friction, we've worked on your problem under a different name.

How do we find out which archetype we're in?

Answer the four questions honestly and it's usually obvious within ten minutes. If you'd rather have it scored, our readiness check walks the same ground in a structured way and takes about five minutes.

Find out where your pipeline actually sits

Run the readiness check for a structured view of your delivery constraints, or book a call and we'll work through the four questions with you directly. No pitch deck, we'd rather spend the time on your rollback path.

Run the readiness check Book a 30-minute call

Prefer to start from your sector? See Industries We Transform, or go straight to Platform Foundation, Secure Delivery or Embedded DevOps.