The new junior who can't do the builds

You hired a junior to take device builds off the senior team. Instead, someone now shoulder-surfs every build — because forty manual steps and a three-weeks-in new starter is a risk you own personally.

Forty steps, and every one matters

The build document isn't the problem. It's probably good. The problem is that it asks a human being to be meticulous forty times in a row, on a Friday afternoon, on the ninth machine of the day.

So the junior misses the drive-encryption check on one laptop. Or applies the Dell tooling steps to the one Lenovo in the batch. Or skips the locale change because the screen looked right. The machine ships, and the failure surfaces three weeks later — usually on somebody's first morning, which is precisely when you least want IT to look sloppy.

Your options today are all bad: do the builds yourself, shadow every build the junior does, or accept the reworks. Each one means you hired a junior and got no capacity back.

Meticulousness as a system property, not a personality trait

Decolla's position is that you shouldn't need a meticulous person — you need a meticulous process, and the person can be new.

The junior works through a guided wizard against your own Microsoft Intune and Autopilot tenant. Discover asks things a first-week starter can answer: platform, chassis, scenario, make. From there, they pick from a curated catalogue of 260+ industry-tested build items across 21 sections — policies, scripts, hardening, and the recurring mundane helpdesk fixes, built in as part of the process.

Critically, the catalogue is relevance-filtered and intelligently defaulted by a conditional engine:

• OEM tooling matches the make they selected — the Lenovo steps never appear on a Dell build
• Power configuration follows the chassis
• Drive strategy, locale, the HVCI gate, and existing-vs-new device handling are defaulted sensibly

The junior isn't writing PowerShell or interpreting a wiki. They're choosing from a vetted list where the irrelevant options were removed before they could pick them.

The plan is where you come back in

Nothing runs on approval by vibes. Before anything executes, Decolla produces an itemised written plan: every item, what it does, how it's delivered, and its reversibility class — automatic, reversible, or flagged irreversible so it stands out before you commit.

The junior defines the build in minutes; you read the plan and approve it. Then deployment runs unattended in your tenant — at Microsoft's pace, to be clear, because installs, sync and ESP are Microsoft's machinery and no tool honestly changes that. Decolla's speed is in the assembly: the weeks you'd spend building and testing your own script library collapse into picking from one that already exists.

If an item turns out to be wrong, roll it back individually — or roll back the whole build. Rollback covers Decolla's own changes only; it will not unstick a failed ESP or reverse a Microsoft install failure, and we'd rather tell you that here than let you discover it later.

What changes on your side of the desk

Delegation stops being a transfer of risk. The junior gets a build they can genuinely own in week one — and because every plan item says in plain terms what it does, the plan doubles as a syllabus. They learn the build by reading it, not by breaking it.

You get a review artefact instead of a shadowing rota: one written plan to approve, and a record of exactly what was approved for every machine, with a defined route back for anything Decolla changed. The senior team gets their afternoons back.

And because it all runs in your own tenant — with the Graph scopes published in full before you connect — you're not handing your estate to anyone else's infrastructure to get there.

Built by people who did these builds by hand

Decolla is a product of The Cloud Platform Ltd, a UK IT consultancy. The catalogue exists because these are the builds we have been doing manually, for real customers, for years — including all the tedious steps a checklist assumes someone will remember.

It's currently in private build. If handing the builds to your junior — without handing over the risk — is a problem you recognise, the early-access waitlist is the way in.