Nobody should get local admin just to run Sage

There is a small, quiet indignity that happens in offices everywhere - and the usual fix trades your security for a working business. Decolla exists to end that false trade. Here is what we have built, and what we are building, to do it.

An old but essential program - an accounts package, a stock system, a bit of line-of-business software the whole company runs on - throws up an error the moment you lock the machine down properly. It cannot write to a folder. It cannot touch a registry key. It refuses to open.

So the person holding the keys does the thing they know will work: they hand the user local administrator rights. One click, problem gone. Except now that user can install anything, break anything, and be phished into handing an attacker the whole machine. A one-app problem has been solved with an every-app-sized hole.

We are building Decolla because that trade - security or a working business - is a false one. And once we started pulling that thread, we found a dozen other places where the tools meant to manage Windows quietly assume you are a specialist with a spare afternoon.

Grant the one thing, not the whole machine in design

When a security policy breaks an old application, the honest question is not "should this person be an admin?" It is "what, exactly, does this program need in order to run?" Almost always the answer is small and specific: write access to one folder, a particular registry key, a single file it updates on launch.

Decolla's least-privilege diagnostics agent - in active design now - is built around exactly that. It watches what the application is actually reaching for, identifies the precise file, folder or registry path it needs, and is designed to grant just that, and nothing else. The user gets a working program; the machine keeps its guardrails; nobody becomes a local administrator to run one piece of software. It is the single biggest daily frustration of every admin we have spoken to, answered not with a workaround but with the correct answer: least privilege, applied surgically.

Pick apps like a shop, they install themselves built

Deploying software through Intune the traditional way means packaging: wrap an installer as a Win32 app, work out the silent-install switches, write a detection rule, test it, repeat for every application. Skilled work - and for a non-specialist, a wall.

Decolla replaces the wall with a shop. You see a grid of tiles - the apps a business actually uses - and tick the ones you want. Behind that, Decolla fetches each app from its official source, packages it as a proper Intune Win32 app, generates the detection logic, and installs it on every device. No scripts, no packaging, no switches to look up. This is built and running today for early-access members - not a mock-up, not a slide.

The app that isn't in any store built

Every real business has one: the RMM agent, the VPN client, the bespoke tool a vendor emailed you as an MSI five years ago. Curated stores never cover these. So Decolla lets you upload any MSI or EXE and reads the installer to understand it. An MSI helpfully describes itself - its ProductCode becomes the detection rule, its silent-install behaviour is worked out for you - so your custom app deploys exactly like a store app. And where those installers carry secrets, like an RMM enrolment token, they are redacted and kept private to your tenant. Your software gets deployed; your keys never go wandering. This is built too.

A stick that builds the whole machine in design

Some jobs still start with a bare machine on a bench. For those, Decolla is designing a bootable provisioning USB: one stick carrying your own Windows media, an auto-executing payload, and the app installers. You boot from it and walk away - it installs Windows, applies the configuration, and installs the apps, unattended. One stick, one boot, a finished machine.

Bring your old world with you in design import: built

The hardest part of adopting anything new is the estate you already have - years of Group Policy, logon scripts and installers accreted across a domain. We are building a small self-serve tool you run once on your server that collects your whole GPO estate - the policies, the scripts, the installers - so Decolla can map it onto your new build automatically. What used to be a manual migration project becomes a single run.

And if what you have is documentation rather than a live domain, that already works: drop in a Word doc, a spreadsheet or a GPO export, and Decolla reads it and pre-selects the matching items on your build, each one flagged "from your docs" so you can see exactly why it is there.

Why it compounds: the learning flywheel in design

Here is the part designed to get better the longer it runs. Every import into Decolla - every GPO estate, every build document, every custom app - teaches it real, working techniques: how businesses actually configure, package and fix things in the wild. Anonymised and consented, those lessons are designed to refine a shared best-practice repository that improves every future build. The tools built for specialists are static; they know what their authors coded and no more. Decolla is built to get smarter with use - without anyone's private data ever being part of the deal.

An honest note on safety

None of this works if you cannot trust it, so a few things are non-negotiable by design. Decolla is reversible by default, and every change comes with a real, plain-English reason - no silent tinkering with machines you are responsible for. Secrets never leave your tenant. And we never redistribute Windows or vendor binaries; Decolla orchestrates installs from official sources, it does not become an unlicensed software mirror. Least privilege is not just a feature here - it is the disposition of the whole product.