The guy on holiday

Every IT team has one person who actually knows how the machines get built. This page is about the two weeks they're away.

It's always one person

Every team has him. The engineer who set up Autopilot two years ago, who knows which of the forty scripts in the Deployment folder are still live, why the laptops get a different power profile to the desktops, and which app has to land before the VPN client or the whole thing wedges. None of it is written down — not because anyone was lazy, but because it accreted. Each fix was ten minutes at the time, and nobody schedules documentation for a ten-minute fix.

Then he books a fortnight off. A new starter's laptop arrives on day three, the build fails at a step nobody else can name, and the person left holding it is the IT manager — the one who owns the risk but not the detail.

Documentation was never going to fix this

The standard answer is “write it down”. Every IT manager has tried. The wiki page gets written in a quiet week and is stale by the next change to the tenant — a renamed configuration profile, a new app version, a script edited in place.

Documentation is a snapshot of a moving system, maintained by the one person who doesn't need it. The knowledge and the record live in different places, and only one of them gets updated when something changes. Asking a busy engineer to maintain both is asking them to do the same work twice — and the second copy always loses.

A build that exists as a plan, not a memory

Decolla's position is that the build itself should be the document. It works over your own Microsoft Intune and Autopilot tenant, and every build starts as a written plan: an itemised list of everything the deployment will do, where each item shows its delivery method and its reversibility class:

• Auto — reverses automatically;
• Reversible — can be rolled back per item;
• Irreversible — flagged plainly, so you see it before anything runs.

You read the plan and approve it; only then does deployment run, unattended, in your tenant. That plan is legible to anyone on the team, not just whoever assembled it. When someone asks “what's on our machines, and why?”, the answer isn't in anyone's head or on a stale wiki — it's the plan that was approved. And the person running a build no longer has to be the person who understands every line of it.

The Library replaces the folder of scripts

The deeper key-man problem isn't the plan — it's the accumulation. The scripts, the fixes for the recurring mundane helpdesk issues, the hardening steps, the OEM quirks. That took years to gather and would take weeks to rebuild from scratch.

Decolla ships with a Library: a curated catalogue of 260+ pre-built, industry-tested build items across 21 sections — policies, scripts, fixes and hardening — filtered for relevance and intelligently defaulted by a conditional engine: OEM tooling matched to make, power settings to chassis, drive strategy, locale, existing estate or new. A guided wizard walks anyone technical through Discover, Configure and Pick, and defining a build takes minutes rather than a weekend of reverse-engineering a colleague's scripts. Nobody on your team has to have written any of it for all of it to be usable.

What this doesn't do — worth saying plainly

Decolla does not make Windows installs, the Enrollment Status Page or Intune sync any faster. Installs run at Microsoft's pace; no tool changes that. What it removes is the assembly work — and the dependence on whoever did it last time.

Rollback covers Decolla's own changes, per item or whole build; it won't rescue a failed Microsoft install. And the Graph permissions Decolla requires are published in full before you connect, so you can review exactly what it can touch in your tenant.

Decolla is a product of The Cloud Platform, a working UK IT consultancy — this scenario is one we know from the inside. It's currently in private build. If the fortnight-in-Tenerife problem is one you own, the early-access waitlist below is the way in.