The Walkaway Test — Designing Software That Outlives Its Creators

The Question Nobody Wants to Answer

Every software team knows about the bus factor. Few take it seriously.

The bus factor measures how many people need to get hit by a bus before a project stalls. For most startups, it's one. For most enterprise teams, it's two or three. Everyone agrees this is a problem. Nobody does anything about it.

We couldn't afford that luxury.

Our software — De Novo xGrid — runs on Raspberry Pi devices in disaster zones. Field hospitals. Community shelters after earthquakes. Places where "call the vendor" isn't an option because there's no phone signal, no internet, and possibly no vendor anymore.

So we asked a harder version of the bus factor question:

If the entire development team vanishes tomorrow, can the deployed systems keep running indefinitely?

Not "for a few days until we hire replacements." Indefinitely.

Five Tests, No Exceptions

We formalized this into the Walkaway Test — five acceptance criteria that every release must pass. The name is deliberate: not "disaster recovery test" or "continuity plan review," but walkaway. As in: the developers walk away, and the system keeps going.

WK01: Offline by Default. The system must operate with zero network connectivity. Not "graceful degradation" — full operation. Every one of our 15+ PWAs works offline. Patient registration, medication dispensing, blood bank management, surgical scheduling. All of it. Network is a bonus, not a requirement.

WK02: Hub Recovery from Edge. If the central Raspberry Pi is physically destroyed, any surviving phone or tablet must be able to rebuild it. We call this the Lifeboat Protocol. A nurse scans two QR codes from her phone to a fresh $80 Raspberry Pi. Data flows back. The starfish regrows its limb. We validated this in a 12-step test on January 26, 2026. Pass rate: 100%.

WK03: Zero IT Dependency. If a system requires SSH access, command-line interventions, or log analysis to function, it fails this test. Our operators are nurses and logistics staff, not engineers. Every operation happens through the PWA interface.

WK04: No License Lock-in. No call-home. No subscription validation. No expiration. Once deployed, the software belongs to the field team. If our company disappears, the software doesn't care.

WK05: Human-Auditable Data. If you don't trust the software anymore, you can still verify the data. SQLite databases open in any tool. Every record has timestamps and operator IDs. You don't need our software to read your own data.

What "Bus Factor Approaching Infinity" Actually Means

On January 27, 2026, after passing all five tests, we wrote one line in our internal log:

Bus factor approaching infinity.

This sounds like bravado. It's not. It's a precise engineering statement.

Traditional bus factor counts people. If three people leave and the project dies, your bus factor is three. Our version counts dependencies on the organization itself. After WK01-WK05, the deployed system has zero dependencies on De Novo Orthopedics — no servers, no licenses, no credentials, no ongoing maintenance. The bus factor isn't about how many people can leave. It's about whether the entire company can leave.

The answer is yes.

The Uncomfortable Design Philosophy

Most software businesses are built on dependency. Recurring revenue depends on customers needing you next month. Cloud hosting means the vendor holds the keys. License servers ensure compliance — and ensure you can't leave.

The Walkaway Test inverts this. Every design decision is evaluated through one lens: does this make the user more or less dependent on us?

This sounds like bad business. It's actually the only honest approach when your users are running a field hospital in a disaster zone. "They need us but can't reach us" is functionally identical to "they don't have the software at all."

Dependency that can't be fulfilled is worse than no dependency. At least without the software, people know to use paper. With a locked-out system, they might waste time trying to fix it.

Three Questions for Your Own Systems

You don't need to build disaster medicine software to benefit from walkaway thinking. Start here:

How long does your system run without network? If the answer is zero, every network outage is a full outage. That's a choice you're making.
Where does your data live, and who can access it? If the answer is "one cloud account controlled by one person," you've centralized your risk in exactly the way the cloud was supposed to prevent.
Can your users export everything without your help? If not, you're not selling a product. You're selling access to a product. Those are different things with different ethical implications.

The Walkaway Test isn't a testing methodology. It's a design philosophy that asks: what would you build if you assumed you wouldn't be around to maintain it?

The answer, it turns out, is better software.