Moving a module off the offline app, with no specification to work from

Nothing was written down. The specification was the existing flows, and those had been shaped by an offline device — draft-first, one user at a time, sync-aware.

Office staff online do not have those constraints, and they do have ones the mobile flows never handled: several people in one document, and real concurrency. A faithful port would have carried offline assumptions somewhere they are wrong and reproduced the collisions instead of removing them.

So it was not a migration in the mechanical sense. It was re-deciding what the flows should be, at the pace of one.

• ~1,100 files across the web app and the API, in < 4 weeks, as an explicitly AI-assisted workstream — then hardened by an audit-and-refactor pass across both surfaces.
• Workflows redesigned for online multi-user use rather than ported, with every deliberate divergence recorded in a decision record so a later reader can tell a decision from an accident.
• Cutover data operations run as executable runbooks: dry-run defaulting to true, numbered stop conditions, idempotent upserts, one-way markers, and a written result per run — so a migration against a live customer database is reviewable and repeatable rather than a one-off session.

files across web and API

~1,100files across web and API

elapsed

< 4 weekselapsed

The release gate, the permission matrix and the documentation contract all existed before any agent ran through them. It was fast because the acceptance criteria were written first.

• Next.js
• NestJS
• TypeScript
• Playwright
• agent runbooks