Moving off a no-code platform means keeping the years of decisions encoded in it and dropping the workarounds it forced. Those are two different things, and the method is mostly about telling them apart.
Platforms stop being right at a predictable point: the workarounds outnumber the features, a pricing or limits change lands without warning, and something the business needs (multi-currency, real permissions, an integration) cannot be done at all. This is the method I use from there.
Step 1: Tear down before you build
Walk every screen with someone who uses it daily, and write down what it does in terms of behaviour, not the platform’s mechanism. For each screen: which records, which fields, which actions, what the user sees next, who can see it. For each automation: what triggers it, what it changes, and whether it carries business logic or is a one-line convenience.
The teardown is the specification. The platform is not. For a CRM this came to thirteen screens, seventeen tables and twenty-four automations, and the written version ran to a few pages. It is the most valuable document in the project; everything else is derived from it. A template is at the end of this page.
Step 2: Profile the live data
Before designing anything, export the real data and look at it. Vocabularies written into the screens (statuses, priorities, categories) are often invented by whoever built the screen and quietly replaced in practice. In one port the spec’s status, priority and effort lists were all wrong; the values in daily use won. Wide tables under-described by the UI get verified column by column against the export.
Step 3: Sort every mechanism
Go through the teardown and mark each mechanism as one of two things.
Product decisions are how the business wants to work. They are kept exactly. One active timer per user. Invoices carrying their own rate and currency. A daily exchange-rate job that caches the rate. Every payment-provider event logged verbatim before anything is reconciled.
Platform workarounds are things the platform forced. They are rebuilt the way the target stack does them. The recurring ones:
| Workaround in the no-code app | Why it existed | What it becomes |
|---|---|---|
| A one-row table holding per-user interface state | No client-side state | Component state or a URL parameter |
| A hand-rolled counter with row locking for ticket numbers | No schema primitives | An identity column, gaps accepted |
| A scoping check repeated in every route | No database authorization layer | Row-level security policies |
| A logging helper called at every write | No triggers | Triggers, which a new code path cannot skip |
| A “preview as user” switch that spoofed identity | Single-session builder | Deleted. Seeded per-role dev accounts instead |
| Style hacks fighting the platform stylesheet | Locked theming | Ordinary theme classes |
| Cache-busting URL tricks for images | No object storage | Public bucket URLs |
The identity-spoofing one matters. Carried over, it is an impersonation backdoor. Workarounds can be security holes, not just clutter.
Keep an explicit table of what the teardown asked for that you are deliberately not building, so every divergence is reviewable rather than discovered.
Step 4: Rebuild the flows the team knows
The screens the team uses every day are the interface. Rebuild those flows so nobody needs retraining: same records, same actions, same order of operations. Under them, use the target stack’s primitives for the workarounds above.
Where the business logic lived in automations, only the scheduled jobs and webhook flows tend to be real logic; the navigation and email one-liners become ordinary buttons. Put authorization in the database if the app is multi-tenant, and write the policy tests before the first screen, so every screen inherits isolation.
Step 5: Migrate and run side by side
Plan the data migration from the export profiled in step 2, including history that the old app kept in odd places. Run the old and new systems in parallel for at least one full business cycle (a month of invoicing, a quarter of reporting), reconciling totals between them. Cut over when the reconciliation is clean, not when the new one looks finished.
Step 6: Keep it running
The new system is ordinary software on ordinary tools. Put it on a monitoring and maintenance rhythm from day one: dependency updates, a scheduled security pass, invariants on the numbers the business relies on. The reason to leave the platform was to own the change rate; that only holds if someone is responsible for it.
Teardown template
For each screen
- Name and purpose in one line
- Records shown, and the fields of each
- Actions available, and what each changes
- Navigation: where you arrive from, where each action leads
- Visibility: which roles see it
- Platform mechanisms noticed (helper tables, counters, per-screen checks)
For each automation
- Trigger
- What it reads and writes
- Business logic or convenience?
- Keep, rebuild as primitive, or drop
For the data
- Every table and its real row count
- Vocabularies in use, from the export, not the screens
- Cross-table references and where they break
Changelog
- 2026-09-05: first version.
- 2026-09-08: opening leads with the principle; template collapsed; short version added.