The bus theory is a thought experiment from software engineering: if you got hit by a bus tomorrow, could someone else pick up your work?
It sounds morbid. It's actually a practical question about the tools you choose, the way you document what you build, and whether the thing you hand off can outlive you.
For GIS developers, the answer divides cleanly along one line: thin HTML or Experience Builder.
I could train a motivated high school student to maintain one of my SDK sites in under an hour. Teaching them to maintain an equivalent Experience Builder app would take weeks — possibly months.
The Experience Builder Inheritance Problem
An Experience Builder app is not a file. It's a configuration state distributed across an AGOL item, a draft config, a published config, a set of data sources, web maps, web map layers, popup templates, Arcade expressions in at least three different contexts, sharing settings, and a deployment URL that may or may not reflect the current draft.
When you open someone else's EB app to understand it, you open the editor. You see a canvas with widgets. You click a widget to see its configuration. You find a data binding. You follow the data binding to a data source. You follow the data source to a web map. You open the web map in Map Viewer to understand the layer. The layer has a popup. The popup has Arcade. The Arcade references fields you can't see without opening the feature layer in a separate tab.
You are now five tabs deep and you haven't found the thing that's broken yet.
There is no single place where the logic of an EB app lives. The configuration is the app. Understanding the configuration requires navigating an interface that wasn't designed for reading — it was designed for building. Those are different things.
The Thin HTML Alternative
A thin HTML file is a file.
Open it in any text editor. Read it top to bottom. The HTML is the structure. The CSS is the style. The JavaScript is the logic. The SDK calls are there in plain text, in the order they execute, with the field names visible, the layer URLs present, the renderers defined as objects you can read.
There is no hidden state. There is no configuration panel. There is no draft vs. published split. What you see is what runs.
If the person who comes after you knows any web development — any at all — they can understand what the file does within minutes. If they don't know web development but they know how to read, they can find the part that's broken, because the part that's broken is in the file.
<!-- This is the entire shelter monitor.
The layer URL is on line 47.
The renderer logic is in buildRenderer() starting at line 112.
The click handler is in view.on("click") at line 198.
That's it. That's the whole app. -->
The comment above is not an exaggeration. In a well-structured thin HTML app, you can tell someone exactly where everything is. In an Experience Builder app, you cannot, because "where" is not a concept that applies.
What Maintainability Actually Requires
Maintainability isn't about documentation — though documentation helps. It's about whether a person with normal skills and normal time can pick up the work.
EB fails this test not because it's poorly designed, but because its complexity is the point. EB is powerful because it lets non-developers build sophisticated apps through configuration. That configuration, accumulated over months or years, becomes an artifact that only its author can fully navigate. The tool optimizes for building, not for handoff.
Thin HTML fails the test when it's written badly — obfuscated logic, no comments, minified code, dependencies on undocumented external services. Written well, it's the most maintainable GIS artifact you can produce.
The difference is that maintainability in thin HTML is a choice. You can choose to write clear code, to name your functions well, to leave comments at the entry points. In EB, maintainability is constrained by the tool. There is no version of a complex EB app that a new person can fully understand in an afternoon.
The Organizational Argument
Most GIS developers in organizations are the only person who knows how their tools work. That's not a failure of the developer — it's a structural condition that follows from the way EB apps are built.
When that developer leaves, the app continues to run, because AGOL keeps it running. But nobody can maintain it, because nobody understands it. New requirements get met with new apps. The old apps accumulate. The organization ends up with seventeen EB dashboards, four of which are live, none of which anyone is confident enough to modify.
Thin HTML files don't work this way. A file in a GitHub repository is something an organization owns. It's something a new developer can fork, read, modify, and deploy. It's something that can be version-controlled, reviewed, and handed off with a README.
The bus theory, applied to GIS development at an organizational level: build things your successor can maintain. The ArcGIS JavaScript SDK, deployed as thin HTML, is the answer. Experience Builder is the thing your successor will politely archive.
I've maintained both. The difference in handoff quality is not marginal. I could train a motivated high school student to maintain one of my SDK sites — a thin HTML file with a working ArcGIS map — in under an hour. Show them where the layer URL is. Show them where the renderer gets set. Show them the click handler. That's the whole app.
Teaching the same student to maintain an Experience Builder app of equivalent complexity would take weeks, possibly months. Not because they aren't capable — because EB requires understanding an organizational layer structure, a draft/published config split, Arcade in three different contexts with three different return type requirements, a widget system, sharing settings, and a set of interactions between panels that are not documented anywhere and only become visible when something breaks. Each piece requires the previous pieces to make sense. There is no entry point.
Build things that outlive you. Thin HTML outlives its authors. Experience Builder outlives its version.