Why I built WinModes instead of debloating Windows

I use one Windows 11 laptop for three different things. When I code, it runs WSL, Docker Desktop and several AI coding tools at once. When I do office work, none of that needs to be running. When I play, I want all the memory back.

The usual answer is a debloat script. I read the code of a dozen open-source optimizers before writing anything, and I ended up building something else: WinModes, a small app that switches the PC between modes and can undo every switch.

What is wrong with debloating

Debloat tools are not bad software. Several of them are carefully written, and I reused ideas from them. They are built for a different problem than mine, for three reasons.

They are permanent. A debloat script uninstalls apps, disables services and writes registry values once. My needs change several times a day. A service that is useless while I play is required an hour later when I open a container.

Their undo restores defaults, not your machine. When an optimizer offers a revert, it usually writes back the value Microsoft ships. That is not the value your machine had. If you or another program had changed that setting, the revert quietly loses it.

Some presets touch things that should never be touched. My research notes list presets that disable memory compression, remove Microsoft Defender or disable the Windows Update service, as defaults and not as options. On a development machine, a preset that stops the wrong Hyper-V service also breaks WSL 2 and Docker.

None of the projects I read does what I wanted: switch from one mode to another and back, show the difference before applying it, and manage WSL and Docker as part of the switch.

Modes instead of tweaks

A mode in WinModes is a description of what the PC should look like for one activity:

• the services this activity does not need;
• the apps to close or launch;
• the power plan;
• whether WSL and Docker Desktop should run.

There are three modes out of the box: Code, Work and Game. Code keeps WSL and Docker running. Work and Game shut them down, because that is where most of the memory goes on my machine.

Before a mode is applied, WinModes shows exactly what it would change, compared with the current state of the PC. Nothing happens until you confirm.

Three rules the engine enforces

1. Record the real state, then undo only what you changed

Before WinModes touches a service, it records the state that service is actually in. “Deactivate” restores that recorded state.

There is one more check. Undo only restores a value that WinModes itself set. If something else changed the service in the meantime, WinModes leaves it alone, because at that point it no longer knows what the right value is.

2. Manual, never Disabled

A stopped service is set to Manual, never to Disabled. Windows or another program can still start it when it is needed. A service that another running service depends on is skipped. Apps are asked to close; they are never force-killed.

These changes take effect immediately. No reboot is needed, and none is needed to undo them.

3. A blocklist that no mode can override

The file data/protected.json lists what no mode may stop, disable or remove:

• security: Microsoft Defender, third-party antivirus, the firewall, Windows Update;
• WSL, Hyper-V networking and Docker components;
• winget, the Microsoft Store, Edge and WebView2;
• developer and AI tools.

The list is enforced by the engine whatever a mode profile says. A badly written profile cannot weaken the machine.

Keeping administrator rights small

Changing a service needs administrator rights. Running the whole app as administrator would give a dashboard, a process list and a settings page far more power than they need.

WinModes splits the work in two. The main window never runs as administrator. Service changes go through a small separate helper that asks for permission once per switch.

The installed version puts the blocklist under Program Files, where changing it also needs administrator rights. The portable build is not hardened in this way, and the README says so.

Seeing where the memory goes

The second half of the app is about measuring. The dashboard shows CPU and memory with a 60-second history, and the Processes page shows the process tree.

The page I use most is AI tools. It lists every running session of Claude Code, Claude desktop, Codex, Cursor, VS Code and others, with the project folder each one works in and all the processes it started. When memory runs out, I can see which session to close instead of guessing.

What it does not do yet

WinModes is an early version. It works on my machine and the engine is covered by automated tests against fake services, but it has not been tested on many PCs.

• Work and Game modes shut down WSL and Docker Desktop. Running containers end, and undo does not restart them or reopen closed apps.
• The packages are not code-signed yet, so Windows SmartScreen warns on first launch.
• The bundled profiles were generated for my laptop. The repository has a script to export your own inventory and regenerate them.
• The interface is in English and dark only.

Try it

WinModes is free for noncommercial use, under the PolyForm Noncommercial license. The installer and a portable zip are on the releases page, and the source builds with the .NET 10 SDK.

If you try it, start with the preview of a mode and read what it would change before you activate it.