Fedi's portal was rebuilt on the current platform with no DNS change and a byte-identical history

Everything worked. Nothing new could arrive.

Fedi's portal was forked from our platform in April 2026 and then did what forks do. The platform kept moving. The fork did not. By the time we looked at it properly, it was roughly 170 schema versions behind.

The thing about that kind of drift is that it produces no symptoms. Every page loaded. Every custom workflow ran. Nobody filed a bug, because there was no bug to file. What there was instead was an absence: every improvement shipped to every other client in those months had stopped arriving here, and the client was paying for a product that had quietly stopped being delivered.

A rebuild, underneath the people using it

We chose to rebuild rather than migrate. Migrating 170 versions of schema across a fork with its own tables is a sequence of small risks, each of which has to go right, and the end state is a database nobody fully trusts. A rebuild has one large risk, which is the cutover, and you can plan a cutover.

So: the current platform, a fresh database, and the custom work grafted back on. Twenty-one route segments that exist in this client's repository and in no other and not in the platform. Release documentation drafted from a signature-verified webhook and held behind an approval. Help-centre updates proposed with a diff and a preview and approved one item at a time rather than in a batch, because a batch hides the bad one. A dashboard for what the models actually cost, per surface.

The cutover needed no DNS change at all. The portal is served through a shared router, so moving it meant changing three database pointers and the brand variables. Nobody watching had a reason to notice.

The history moved with it, and we checked rather than assumed: three conversations, fourteen messages, nine read receipts, compared on both sides afterwards. The old database was kept intact as a one-command way back, which we did not need and would have wanted badly if we had.

Nothing publishes itself

Every one of the three workflows ends at a person. A release event produces a draft, not a document. A proposed help-centre change produces a diff, not an edit. Approval is per item, and the reject path carries a reason, because a rejection nobody explains teaches the system nothing.

One thing that came out of this build outlived the engagement. Release documentation was the first job on our platform that ran inside the application, rather than posting out to an external pipeline and waiting. That pattern is now how every in-application job is written, for every client. The work was paid for once by one company and every client since has ridden on it.

A clean rebuild that nobody has opened

3 of 3

Twenty-one bespoke route segments. A hundred and thirty-one documents indexed in the brain. Three of three conversations migrated with every message and every read receipt intact. Zero DNS changes at cutover. A twenty-nine page manual.

And zero client accounts have signed in to the rebuilt portal.

The engagement was stopped at the client's request during a restructuring in August, and we left the portal, the brain and all three workflows running rather than tearing them down. That is the context, and it is not an excuse. The rebuild was sound and nobody used it, and a case study that printed the first half of that sentence without the second would not be worth reading.

What the engagement did produce, permanently, is the in-application job pattern that every client now runs on. If you want the version of this with people actually using the thing, the two knowledge-brain builds are the ones to read: one here and one here.