Build for the network that fights you
Most tools are built for a friendly network: install what you need, pull a dependency, phone home for updates, connect to the thing you're managing. Then you take that tool into a bank, a hospital, a defense contractor, an air-gapped OT network — and every one of those assumptions is a wall.
No admin rights. No package managers. No Docker. No outbound internet from the boxes that matter. And a procurement-and-security queue that turns "can I use this small helper" into a quarter-long project. In that world, the tool that wins isn't the most capable one. It's the one that asks for nothing.
The constraints, turned into rules
- One self-contained file. HTML with the CSS and JS inlined. It runs from a file share, a USB stick, an email attachment. No build, no bundler, no install.
- No network. No CDN font, no analytics beacon, no "check for updates." The moment a tool needs the network, it stops working exactly where you need it most.
- Never connect to the target. The tool doesn't open a connection to the database, the cluster, the anything. You run read-only commands yourself and paste the output in. The tool reasons; it doesn't reach.
- Read-only, always. Nothing it produces changes state. That's what makes it safe to run during an incident and easy to get approved before one.
Why the constraints made it better
Here's the counterintuitive part. Every one of those limits, which reads like a compromise, turned out to be a feature.
"No network" made it trustable. A tool with zero egress has no data-exfiltration story to review. A senior engineer reads the file, sees it talks to nothing, and approves it on sight. The legibility is the security review.
"Never connect" made it universal. Because it works on pasted text, it doesn't care whether you're on SQL Server 2016 or 2022, on-prem or in a locked-down VM, connected through six jump boxes or none. Text in, triage out.
"One file" made it spread. Adoption in a hostile environment isn't a download page — it's someone emailing a colleague an attachment. A single file is the distribution channel.
The best way to build a tool people are allowed to keep is to build one that asks for nothing.
The one rule that keeps it field-ready
The temptation, always, is to add the one convenient thing — a CDN font, a fetch to enrich the data, a tiny backend "just for this feature." Each one, individually, seems fine. Together they're how a field kit quietly stops working in the field.
So the rule is absolute: if a change would make the tool need a network to do its core job, it doesn't go in the offline kit. Fancier features live in a separate, connected tier for the people who can reach out. The kit that goes into the hard environment stays pure. That line — drawn once and held — is the difference between a tool that works in the demo and a tool that works at 2am on the box that can't see the internet.