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. None of them has shipped yet.

1. AfterPatch: runtime repair

First release. 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

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 transforms, and an HTTP compatibility test suite.

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

Watch files, databases, HTTP traffic or process output, and turn meaningful changes into webhooks for software that never offered any.

First version: SQLite change detection, file watchers, webhook delivery with retries, and event filters.

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.

First version: SQLite schema diffs, generated compatibility views and migration checks.

6. AfterConfig: configuration overlays

Change how an application behaves with checked, reversible overlays, so you never edit vendor files that the next upgrade will overwrite.

First version: layered YAML, JSON, TOML and environment-variable configuration with validation.

7. AfterTest: regression tests from real traffic

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: HTTP capture through the AfterPatch proxy, fixture files, replay and a comparison that understands JSON.

8. AfterBridge: small adapters

Translate protocols, formats and event streams with small adapters, without a big integration platform.

First version: HTTP-to-webhook, CSV-to-JSON and SQLite-to-HTTP adapters sharing one configuration format.

9. AfterGuard: a security boundary for old software

Add rate limits, request checks, IP rules, security headers and authentication in front of applications that can’t do it themselves.

First version: an HTTP security gateway with local rules and request logs, built after a written threat model.

10. AfterDiff: what changed in behaviour

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: a command that runs two targets and writes a structured difference report.

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.