Friday, 4pm: new starter Monday

It is the per-hire scramble every IT manager recognises: the start date is real, the laptop is not ready, and "zero-touch" somehow still means someone's Saturday. Here is where that time actually goes — and what Decolla changes.

The Friday email

The offer went out weeks ago, but the confirmation lands at 4pm on Friday: the new starter begins Monday, and could IT sort a laptop? Somewhere there is a device — in a cupboard, or still in the courier's van — and between now and 9am Monday it needs to become that person's working machine.

You know how this goes. Someone stays late, or comes in on Saturday, or the starter spends their first morning watching progress bars while their manager makes apologetic small talk. None of it is a crisis. It is a tax, paid per hire, forever.

Why "zero-touch" still costs a half-day

Autopilot and Intune genuinely do the enrolment. That part works. The half-day goes on everything around it: deciding what this particular person, on this particular hardware, in this particular department actually needs — and then assembling it.

• The app set for their role, and the three exceptions to it.
• OEM tooling and driver updates for whichever make the reseller shipped this quarter.
• Power, encryption and locale settings that differ by chassis and by country.
• The small preventative fixes your helpdesk applies to every machine because you have learned, painfully, what happens otherwise.

A recurring theme on r/sysadmin is the "zero-touch" build that still keeps a technician within arm's reach of the machine for half a day. The installs were never the fixable part — nothing makes Microsoft's provisioning run faster, and anyone who says otherwise is selling something. The fixable part is the assembly: the deciding, the finding, the scripting, the sequencing. That is where the hours actually go.

Define the build once — on a quiet Tuesday

Decolla, built by The Cloud Platform — a working UK IT consultancy that has paid this tax for years — moves the thinking to a moment when nothing is on fire.

A guided wizard walks you through it: platform, chassis, scenario and make first, then configuration, then a curated catalogue of 260+ build items across 21 sections. You are not scrolling through all of them; the catalogue is relevance-filtered and intelligently defaulted — OEM tooling matched to the make, power settings to the chassis, drive strategy, locale, the HVCI gate, existing-versus-new machine handling. The Library underneath is pre-built, industry-tested policies, scripts and fixes — including the mundane, recurring helpdesk fixes and hardening — so weeks of DIY assembly happens in seconds.

The output is not a running deployment. It is an itemised, written plan: every item shows how it will be delivered and whether it is automatically reversible, reversible on request, or irreversible and flagged as such. You read it. You approve it. Nothing runs before that.

Monday morning, honestly stated

With the plan approved, the sealed box goes straight to the starter. First boot, and the deployment runs unattended in your own tenant — your Intune, your Autopilot, with the Graph permissions Decolla asks for published in full before you ever connect. To be clear about the boundaries: installs still run at Microsoft's pace, and a stuck ESP screen is still a stuck ESP screen — Decolla does not pretend otherwise. What changes is that the half-day of assembly is already done before the box was even posted, and if an item misbehaves you can roll back that item, or the whole build, covering every change Decolla itself made.

The next hire uses the same approved plan. The Friday email becomes an address label, not a lost weekend. Decolla is in private build; if the per-hire scramble sounds familiar, the early-access waitlist is open.