The library

Every Windows estate ends up re-solving the same problems from scratch. The library is where that stops: pre-built, industry-tested build items you select instead of write.

The work that never makes the project plan

Ask anyone who has stood up a Windows estate on Microsoft Intune what took the time. It was rarely the Autopilot profile. It was everything around it: hunting the settings catalogue for the right power behaviour on laptops versus desktops, writing a remediation for the keyboard layout that keeps resetting itself, deciding a drive-encryption strategy, testing a script across three chassis types, and rebuilding — from memory, or from a personal script folder — the fixes you already wrote for the last tenant.

None of it is hard. All of it is slow. And because most of it lives in scattered scripts and old notes rather than anywhere shared, it gets re-solved constantly: by you, by the next engineer, by every team facing the same blank Intune console. The industry keeps paying for the same work, over and over.

Pre-built, not blank-page

The library is Decolla's curated catalogue of pre-built build items — 260+ of them, organised into 21 sections. It covers three kinds of work that normally eat your weeks:

• The deliberate configuration. Policies and profiles for the decisions every build has to make: OEM tooling matched to the make, power behaviour matched to the chassis, drive strategy, locale, and the rest.
• The mundane fixes. The recurring helpdesk items every estate hits and every team quietly re-solves — pre-built once, tested, and included as part of the build rather than as tickets waiting to happen.
• The hardening. Security tightening built into the process itself, delivered through Decolla's own mechanisms — nothing extra to buy, license or bolt on.

You don't wade through all 260+. When you define a build, Decolla's conditional engine filters and defaults the catalogue against what you've told it — platform, chassis, scenario, make, existing estate or new — so a laptop fleet never sees desktop power plans, and sensible choices arrive pre-selected for you to keep or override.

How an item earns its place

Decolla is a product of The Cloud Platform Ltd, a working UK IT consultancy — and the library is what consultancy work becomes when it's done repeatedly and kept. An item starts life as a real fix for a real estate. It survives contact with actual hardware, actual users and actual edge cases. Only then is it generalised, documented and admitted to the catalogue.

Nothing enters the library as a good idea from a blog post. The bar is not does this work in a lab; it's has this already worked where it matters. That's the difference between a catalogue and a collection of snippets you still have to validate yourself.

Where the speed comes from — and where it doesn't

Two honest statements, because you'll be asked to defend this internally.

Decolla does not make Microsoft faster. Windows installs, the Enrollment Status Page, application delivery and policy sync all run at Microsoft's pace. Nothing anyone sells you changes that, and we won't claim otherwise.

What Decolla removes is the assembly. The research, script-writing, cross-referencing and testing that normally sit between we've agreed what the build should be and the build actually exists — the part that takes weeks by hand — collapses into selecting proven items from the library. Work that takes weeks to assemble is picked in seconds, and a complete, itemised build is defined in minutes.

The deployment window stays the same. The engineering weeks in front of it are what shrink — along with the risk of a hand-rolled script that only ever got tested on the machine it was written on.

You still read every line before anything runs

Speed without control is just risk arriving sooner, so the library feeds a gate rather than a trigger. Your selections become an itemised, written plan. Every item states what it will do, how it's delivered, and its reversibility class — reversed automatically, reversible on demand, or flagged as irreversible so you see it before you approve, not after.

Nothing runs until you approve that plan. Deployment then runs unattended in your own Microsoft Intune and Autopilot tenant — Decolla operates over your tenant, not a copy of it — and the Graph permissions it needs are published in full before you connect. Afterwards, you can roll back per item or the whole build. That rollback covers Decolla's own changes only: it will not unwind a failed Microsoft install or rescue a stuck ESP, and the plan never suggests it will.

Decolla is in private build. If the library covers the part of your next rollout you'd rather not hand-assemble again, the early-access waitlist is where it starts.