Why Aftermarket Is Named After Car Parts

The name came first, before any code. It describes a category that already exists in software but doesn’t have a word of its own.

Car people know the word well. The aftermarket is everything sold for a car after it leaves the factory: brake pads, wheels, stereos, the independent garage down the road. The manufacturer doesn’t control any of it, and drivers are better off for that. A car stays on the road for twenty years because someone outside the factory keeps making parts for it.

Software works the same way. Programs outlive their designs. Vendors move on, APIs get rewritten, the team that knew how it all worked leaves. What keeps an old system running is usually something added later, from outside: a proxy rule, a patch, an adapter, a stand-in service. That’s an aftermarket. It just isn’t organised like one.

The tool names follow from it

Each tool is named for what it does to software after the fact. AfterPatch repairs traffic. AfterAPI keeps old clients talking to new APIs. AfterTest records real traffic so a new release can be checked against it, and AfterDiff compares two versions side by side. Afterlife stands in for services that were switched off. The concepts page has the full list.

They all share one command, aftermarket, so the names stay short: aftermarket patch, and later aftermarket adapt, aftermarket record and aftermarket replay.

What the name promises

An aftermarket part has to fit a car it wasn’t designed with. It has to work without the factory’s help. And a good one doesn’t break anything else when you fit it.

That last part is the rule the project is built around. A repair should change the one thing it’s meant to change and leave everything else exactly as it was. The first release is tested hard against that, and the roadmap keeps every tool after it to the same standard.