The build that drifted

Nobody decided to abandon the standard build. It eroded, one reasonable exception at a time — until "standard" described maybe half the fleet, and no one could say which half.

Nobody decided to drift

The standard build was standard once. Then one laptop needed a different power plan for a demo. A driver problem on one model earned a quiet workaround. A new starter needed a machine urgently, so the checklist got skipped — just this once. Each decision was defensible. None was recorded anywhere that matters.

Six months on, you have a fleet where every machine is almost the same. The helpdesk feels it first: fixes that work on one machine fail on its supposed twin. Then it reaches you, because you own the risk — and you cannot state, with confidence, what any given machine actually has on it.

This is not a competence problem. Drift is what happens when the standard exists as an intention — a wiki page, a checklist, institutional memory — rather than as an artefact. Intentions don't version. They erode.

Why builds drift

A few forces push every hand-assembled build off its baseline, no matter how disciplined the team:

• Documentation lags reality. The wiki records what the build was the last time someone updated the wiki. Every undocumented tweak widens the gap.
• Exceptions never fold back in. The one-off fix that worked becomes the way one engineer builds machines — and nobody else's.
• People build differently. Two competent engineers following the same checklist will still make different judgement calls where the checklist is silent.
• Hardware forks the standard. What's right for a desktop is wrong for a laptop; what suits one make needs different OEM tooling on another. Without a structure for those variations, the standard quietly splits into unofficial dialects.

None of this is fixed by trying harder. It's fixed by changing what the standard is.

A standard is an artefact, not a memory

Decolla treats every build as a plan before it is anything else. A guided wizard walks the build: Discover the platform, chassis, scenario and make; Configure; then pick from a curated catalogue of 260+ build items across 21 sections — pre-built, industry-tested policies, scripts and fixes, including the mundane recurring helpdesk fixes and hardening that usually get bolted on later, or forgotten. The catalogue is relevance-filtered and intelligently defaulted by a conditional engine: OEM tooling follows the make, power configuration follows the chassis, drive strategy, locale and the HVCI gate are resolved rather than guessed.

The output is an itemised, written plan. Every item states its delivery method and its reversibility class — automatic, reversible, or flagged irreversible. You read it and approve it before anything runs. Then deployment runs unattended in your Microsoft Intune/Autopilot tenant.

That plan is not a description of the standard. It is the standard — defined in minutes, executed the same way every time.

Drift you can diff

Once the standard is a document, drift stops being a feeling and becomes a diff.

Two machines built from the same approved plan were approved for the same items — so comparing two builds' intent means comparing two plans, line by line. A deliberate exception is a visible one: the demo laptop's plan differs from the baseline in exactly one named item, and anyone can see which. A change to the standard itself is an approved diff between last quarter's plan and this quarter's — a decision on the record, not an erosion nobody noticed.

The weeks of DIY assembly — hunting down scripts, rebuilding policies, re-testing the same fixes every organisation rebuilds from scratch — collapse into selecting from the library. And because every Decolla change is itemised, you can roll back per item or the whole build. Decolla's own changes only: it won't unwind a failed Microsoft install, and doesn't pretend to.

What this does and doesn't fix

Straight limits, because you'd find them anyway. Decolla doesn't make Windows install faster — Microsoft's installs, enrolment and sync run at Microsoft's pace, and any tool claiming otherwise is selling something. And a plan governs what was deployed; it doesn't police what a human does to a machine afterwards. What it gives you is a fleet where every machine started from the same approved, itemised baseline — and where any difference between two builds is something you can put on a screen, in writing, before the audit asks.

Decolla is a product of The Cloud Platform Ltd, a UK IT consultancy that has spent years rebuilding these baselines by hand. It's currently in private build. If a standard that stays standard is the problem on your desk, the early-access waitlist below is the only way in right now.