On a rebuild, keep the product and drop the platform. A firm’s CRM had years of decisions about how the business works encoded in its screens, and a pile of workarounds the no-code platform had forced. Starting fresh loses the first; copying faithfully imports the second. The method that worked separates them.
The system: sales, projects, time tracking and invoicing on a no-code platform, grown to thirteen screens, seventeen tables and two dozen automations. It had hit the ceiling. Multi-currency billing and reconciliation were happening half in the app and half by hand, and the platform’s pricing and limits could change under the business at any time.
Write the teardown first, implementation-neutrally
Before any code, walk every screen and write down what it does in terms of behaviour, not mechanism. Which records, which fields, which actions, what the user sees next. The teardown for the CRM came to four core record types, a time-tracking-to-invoicing chain, three pieces of Stripe integration, a ledger and a pipeline. That document is the specification. The platform is not.
Sort every mechanism into product decision or platform workaround
This is the step that pays. Going through the teardown, each mechanism is one of two things.
Product decisions are kept. One active timer per user, and starting a second stops the first. A daily exchange-rate job that caches the rate so the invoicing screen never calls an API per page view. Every Stripe event logged verbatim to an append-only table before anything is reconciled. These are how the business wants to work.
Platform workarounds are rebuilt the way the target stack wants them. The patterns repeat across every no-code port I have done:
- A one-row “helper” table holding per-user interface state, because the platform had no client state. Becomes component state or a URL parameter, never a table.
- A hand-rolled locked-row counter for ticket numbers, because there were no schema primitives. Becomes an identity column, accepting gaps the way every ticketing system does.
- A scoping check pasted across forty routes, because there was no database authorization layer. Becomes row-level security policies.
- A logging helper called at every mutation, because there were no triggers. Becomes triggers, which cannot be skipped by a new code path.
- A “preview user” switcher that spoofed identity to work around the platform’s single-session limit. Carried over, this is an impersonation backdoor. Deleted, replaced by seeded per-role dev accounts.
Keep a table of what the teardown asked for that you are deliberately not building, so every divergence can be reviewed rather than discovered.
Two corollaries
Live data beats the spec. Before building, profile a real export. In a ticketing port the spec’s status, priority and effort vocabularies were all invented by whoever wrote the screens; the real ones, in daily use, were different and won.
Thin automations do not port. Of the two dozen workflows in the CRM, only the scheduled jobs and the webhook flows carried business logic. The rest were navigation and email one-liners that become ordinary buttons, not a workflow engine.
What the team noticed
Nothing. That was the goal. The flows matched what they had, so nobody was retrained. Invoicing and reconciliation now happen without the spreadsheet, and the system can be extended because it is built on ordinary tools that any developer can read.