What a Software Aftermarket Is and Why You Already Use One
Every developer has fixed software they didn’t write. Most of us just don’t call it that.
You put nginx in front of an old app to add a header it forgot. You wrote a shim so a client from 2017 could keep talking to a rewritten API. You patched a vendor’s config file, watched the next upgrade wipe your change, and patched it again. Somebody on your team keeps a script that “fixes the export” every Monday morning. None of that is in the original product. All of it keeps the product useful.
Cars have a name for this. The aftermarket is everything that gets built around a car after it leaves the factory: replacement parts, upgrades, independent repair shops, tuning kits. It’s a huge industry, and it runs without asking the manufacturer for anything. A garage doesn’t need the source drawings to replace your brakes.
Software has the same industry. It’s just scattered.
Where it hides today
Look at what lives between your systems and you’ll find it. Reverse-proxy rules that rewrite paths. API gateway plugins that rename fields. Monkey patches. Browser extensions that fix a web app the vendor won’t fix. Mock servers standing in for a service that was switched off. Migration scripts nobody dares delete.
Each of these was written in a hurry, by someone who needed one thing to work by Friday. They tend to share three problems:
- Nobody can read them later. A Lua snippet inside a gateway config says what it does to the bytes. It doesn’t say why.
- Nobody can test them. The fix works in production, which is the only place it has ever run.
- Nobody knows what they touched. When something odd happens, there’s no record of which repair changed which request.
What Aftermarket tries to do differently
Aftermarket.dev is a family of tools for this work, with a few habits built in from the start.
A repair is a rule in a file, short enough to read in a code review. Each rule says which traffic it applies to and what it changes, and nothing else. A dry-run mode shows what the rules would do to live traffic before they do anything. Every change lands in an audit log. And every rule can be tested against a saved request, so a repair that worked last month can be checked again today.
The first tool, AfterPatch, does this for HTTP: rename a JSON field, move an endpoint, add or drop a header. The ones after it handle bigger API translations, record-and-replay testing, and comparing two versions of a service. The concepts page lists all of them.
Who it’s for
People who look after software they didn’t build and can’t easily change. That covers a lot of us: the team that inherited an integration, the company that depends on a vendor’s API, the developer keeping an old client alive while the new one is built.
The original code stays exactly as it is. That’s the whole point.