What we build, and why
each one is hard.
Capability and engagement model are different questions. These four are what we build. How you buy them — augmentation, a managed pod, a transformation programme, a build–operate–transfer centre — is a separate decision, and the two combine freely.
Probabilistic systems
AI & Applied ML
LLM applications, retrieval systems, agents and applied ML built to a standard you can put in front of a regulator — with evaluation harnesses, cost controls and failure behaviour designed in rather than discovered in production.
Most AI projects do not fail on model quality. They fail because the team had no way to tell whether a change made the system better or worse, so every release was a judgement call and confidence decayed until the project was quietly shelved.
Software that acts
Agentic Systems & Automation
Systems that choose their own next step — tool-using agents, orchestrated workflows and automation that spans your existing systems — designed so that what they are permitted to do, and what happens when they are wrong, are decided up front.
The hard part of an agent is almost never the model. It is the boundary: what it may do unsupervised, how a half-finished multi-step action is recovered, and how you stop it. Most production systems marketed as agents are workflows with a model in them — and that is usually the correct design, chosen deliberately rather than by default.
Irreversible deployment
Blockchain & Smart Contracts
Protocol and application development where a deployment cannot be rolled back and a defect is a withdrawal. Contract engineering, security review, upgradeability design and the on-chain boundary decision.
Every delivery practice that assumes you can ship a fix breaks here. The response is not to slow everything down — it is to move the iteration upstream, where it is cheap, and make the irreversible step the smallest and best-verified thing you do.
Gated releases
Mobile & Cross-Platform
iOS, Android and cross-platform applications delivered continuously despite a third party sitting between your merge and your users — staged rollouts, feature flags, release trains and a native-versus-cross-platform decision made on economics.
Mobile is the one place where someone else owns your release path. Teams that treat store review as an immovable wall end up with monthly batches and mobile as the slowest thing they own. Teams that engineer around it ship weekly and decouple release from reveal.
The paved road
Platform & Data
The substrate the other three stand on: cloud infrastructure, deployment pipelines, observability, data platforms and the internal paved road that determines how fast every team above it can move.
Platform work is the highest-leverage investment available to a delivery organisation and the easiest to defund, because its return shows up as other teams being faster rather than as anything the platform team can point at. Measure it as adoption and friction removed, or it will be cut.
How the two combine
Capability × engagement model
Any capability can arrive through any engagement model. The capability decides who we put on it; the model decides what we are accountable for and how it ends.
| Capability | Team Augmentation | Managed Pods | Delivery Transformation | Build–Operate–Transfer | AlphaScrum Academy |
|---|---|---|---|---|---|
| AI & Applied ML | Yes | Yes | Yes | Yes | Curriculum |
| Agentic Systems & Automation | Yes | Yes | Yes | Yes | Curriculum |
| Blockchain & Smart Contracts | Yes | Yes | Yes | Yes | Curriculum |
| Mobile & Cross-Platform | Yes | Yes | Yes | Yes | Curriculum |
| Platform & Data | Yes | Yes | Yes | Yes | Curriculum |
The one exception is the Academy, which teaches delivery practice rather than supplying engineers — though each capability contributes its own module, because verification looks different when the thing you are verifying is probabilistic, irreversible or gated behind a third party.