Andy Simon

GTM Systems & Revenue Technology

Go-Live Is Not Adoption: What a Terminal Easter Egg Taught Me

by asimon
adoptionreacttypescriptaccessibility

I shipped a fully-featured terminal for this site — command registry, virtual filesystem, tab completion, accessibility built in. Then I demoted it. The demotion is the lesson.

This site has a hidden terminal. Press the backtick key (`) on any page and a shell slides up: twelve commands, a virtual filesystem, tab completion, command history that survives browser sessions, and accessibility engineering I'm genuinely proud of.

I shipped it as a headline feature, with its own button in the site header. Today the button is gone and the terminal is an easter egg. Nothing about the code changed — what changed is that I stopped pretending it had users. That demotion taught me more than the build did, which is why this post survived the site's editorial cleanup as the catalog's one admitted failure.

(Updated August 2026 — rewritten from a feature tour into the story of why the feature got demoted.)

What I Built

The short version: a keyboard-driven overlay that models the site as a filesystem you can navigate —

/
├── posts/           # All blog posts as .mdx files
├── sandbox/         # Interactive tools
│   ├── roi.txt
│   ├── matrix.txt
│   └── readiness.txt
├── about.txt
└── readme.txt

— with ls, cd, cat, and open behaving the way your fingers expect, plus latest, random, sandbox, theme, help, clear, pwd, and whoami. A command registry with aliases, a reducer-based state context, localStorage persistence for history and working directory. Real engineering, executed carefully. Try it: press , type help`.

How I Shipped It

The scoping discipline was sound, and I'd repeat it:

MVP-0 shipped the minimum that was genuinely usable — help, ls, cd, pwd, open, clear, a toggle, and the Escape key. MVP-1 followed fast with the polish: cat, random, latest, theme, whoami, tab completion, history navigation, focus trapping. Ship something real, then earn the extras — that part worked.

So did the accessibility, because it was designed in rather than retrofitted: role="dialog" with aria-modal and aria-live output, focus trapped while open and restored on close, full keyboard navigation, reduced-motion support. Playwright specs cover all twelve commands, the shortcuts, history, and completion. As craft, the terminal holds up completely.

The Part I Got Wrong

None of that answered the only question that matters after go-live: who was going to use it?

Walk through it honestly. The terminal is a power-user interface — it rewards people who feel at home in a shell. But this site's primary readers are executives and hiring managers evaluating the claims in my resume, arriving with five to ten minutes of attention. They don't want a virtual filesystem; they want the article. The audience that would enjoy the terminal — developers — was never the audience the site is for.

And even for the sympathetic visitor, I'd built no path to the feature. A small icon button in the header, no onboarding moment, no reason to click it before the content they came for. Discoverability wasn't designed; it was assumed. I built the tool for the person I am, not for the reader I have.

When I later audited the whole site against its actual audience, the terminal failed the first question I'd ask of any capability in a professional stack: what job does this do for the person in front of it? The honest answer was "it demonstrates that I could build it." So it was re-scoped to exactly that job: the nav button came out, the backtick stayed, and the terminal became what it always really was — a signature inside the machine for whoever thinks to look.

The Same Failure at Enterprise Scale

I've watched this exact pattern with much bigger price tags. A capability gets licensed, built, or configured; go-live is announced; the project is declared done — and month six finds it unused, because nobody designed the path from "it exists" to "it's how the work gets done." In a GTM stack that's shelfware; the buy-vs-build piece puts it as a capability isn't an asset until someone runs it. The terminal is that rule at hobby scale, with me as both the vendor and the disappointed buyer.

The transferable lesson isn't "don't build fun things." It's that adoption is a design input, not a launch metric. Who will use this, how will they find it, and what were they doing before that this replaces — if those answers don't exist before the build, the build is for the builder. Delivering adoption at organizational scale — enablement, workflow change, the difference between deployed and operational — is where the same failure gets expensive. Don't Be the Relay is that argument applied to an AI rollout: usage numbers climb while judgment leaves the loop.

Where It Landed

The terminal stays. It costs nothing to keep, its test suite protects it, and as an easter egg it does one job well: anyone curious enough to press a backtick on a stranger's blog gets a small, complete, accessible piece of software as a reward — and now, a link to this post explaining why it's hidden.

It's a better feature now that it stopped pretending to be the product.