Project concepts
Plugins, patches, extensions, compatibility layers, migration scripts, monitoring agents and replacement APIs all serve software after its first release. Together they make up a software aftermarket. Aftermarket.dev covers that whole category, and AfterPatch is simply where it starts.
Each concept below is planned as a subcommand of the aftermarket program. A tool moves out into its own binary only if it proves it needs one. AfterPatch, AfterAPI, AfterTest, AfterDiff, AfterConfig, AfterHook, AfterGuard, AfterSchema and AfterBridge have shipped. The others haven’t yet.
1. AfterPatch: runtime repair
Released in 0.1.0. Intercept HTTP requests, rewrite responses, add or remove headers and fix broken API fields, all without rebuilding the application. It’s a programmable repair layer that sits between an application and the service it calls.
First version: one Go binary, YAML repair rules, a reverse proxy, a dry-run mode and an audit log of every change.
2. AfterAPI: API continuity
Released in 0.2.0. Map old endpoints, request fields, response shapes and header conventions onto new ones, so legacy clients keep working after an upstream API changes.
First version: endpoint remapping with path parameters, JSON request and response templates, status and error mapping, and an old client’s test suite as the proof. See the AfterAPI reference.
3. Afterlife: software preservation
Keep discontinued software working by standing in for cloud endpoints or configuration services it can no longer reach. Afterlife only replaces documented APIs. Licence checks and copy protection are out of scope.
First version: a local HTTP service that answers in place of a discontinued application’s documented remote API.
4. AfterHook: events after the fact
Released in 0.5.0. Watch files, databases, HTTP endpoints or command output, and turn meaningful changes into webhooks for software that never offered any.
First version: aftermarket hook, which checks files, folders, HTTP endpoints and command output on an interval, including SQLite through the sqlite3 command, and sends signed webhooks that are retried until delivered. See the AfterHook reference.
5. AfterSchema: database compatibility
Translate old field names and query expectations into current ones, keep compatibility views up to date, and find code that still depends on retired structures.
Released in 0.8.0. First version: aftermarket schema, SQLite schema diffs that mark what breaks old readers, compatibility views generated from a mapping file, and checks that run the old queries against the new schema and compare their rows with the old ones.
6. AfterConfig: configuration overlays
Released in 0.4.0, TOML added in 0.7.0. Change how an application behaves with checked, reversible overlays, so you never edit vendor files that the next upgrade will overwrite.
First version: aftermarket config, overlays on JSON, YAML, TOML and .env files with guards that stop when an upgrade changed something the overlay relies on. In TOML and .env files the changes are made on the vendor’s own lines, so comments stay. See the AfterConfig reference.
7. AfterTest: regression tests from real traffic
Released in 0.3.0. Record real requests and responses, strip out fields that change every time, and replay the traffic against a new release. Sensitive data gets removed before anything is stored.
First version: aftermarket record, a proxy that changes nothing and saves each exchange as a fixture case, with credentials and listed values redacted. See the AfterTest and AfterDiff reference.
8. AfterBridge: small adapters
Translate protocols, formats and event streams with small adapters, without a big integration platform.
Released in 0.9.0. First version: aftermarket bridge, a read-only JSON API over CSV exports and SQLite files, with typed columns, filters and lookups by key. The HTTP-to-webhook direction is covered by AfterHook.
9. AfterGuard: a security boundary for old software
Released in 0.6.0. Add rate limits, request checks, address rules, security headers and authentication in front of applications that can’t do it themselves.
First version: aftermarket guard, an HTTP security gateway with API keys and Basic logins kept as hashes, rate limits, and a refusal of any request that could be read two ways, built after a written threat model. See the AfterGuard reference.
10. AfterDiff: what changed in behaviour
Released in 0.3.0. Send the same inputs to two binaries, services or API versions and compare what comes back, what side effects happen and how long it takes. Source diffs show what was edited. AfterDiff shows what actually behaves differently.
First version: aftermarket replay, which sends recorded requests to two versions of an HTTP service and lists every difference in status, headers and JSON fields, in Markdown and JSON. Since 0.10.0, aftermarket shadow does the same on live traffic: clients get the current version’s answers, and a copy of each request goes to the new version in the background for comparison.
Research directions
AfterInstall would record what an installer changes, so it can be inspected and rolled back. AfterDocs would rebuild API documentation from observed traffic. AfterMock would stand in for a missing service using recorded interactions. AfterDeploy would run checks after a deployment and make small, scoped fixes. AfterUpgrade would explain why an upgrade broke something. AfterPlugin would add extension points to applications that have none.
AfterTrace is the most ambitious idea here. It would attach to a process that’s already running and work out its dependencies, network calls, file activity and configuration use, with no instrumentation added beforehand. Doing that across operating systems is much harder than anything in the first wave.
How the first concepts compare
| Concept | Difficulty to build | How different it is | Commercial potential |
|---|---|---|---|
| AfterPatch | Medium | High | High |
| AfterAPI | Medium | High | High |
| Afterlife | Medium to high | Very high | Medium |
| AfterHook | Low to medium | Medium | Medium |
| AfterTest | Medium | High | High |
| AfterDiff | Low | Medium | Medium |
| AfterConfig | Low | Medium | Medium |
These are judgement calls, not market research, and the other ideas haven’t been scored. The build order is AfterPatch first, then AfterAPI, then AfterTest with AfterDiff, because each one reuses the proxy the first one builds.