Framework
Next.js 16 (App Router)
React 19, TypeScript strict, server components default
For CTOs and founding engineers
You built the Bubble app. You’ll own whatever replaces it. Here’s exactly what we’d build.
Skip the sales tour. This page is the architectural document — stack choices, data-migration approach, cutover plan, what we keep, what we don’t touch, and the failure modes we plan for. No platform-bashing. No SOWs. If something here doesn’t match how you’d build it, push back on the call.
Stack we build on
Boring, hire-able, modern. Nothing exotic, nothing locked in.
Every choice optimises for one thing: a senior engineer at any salary band should be able to read it and ship within a week of joining.
Data layer
Postgres + Drizzle
Schema-first migrations, type-safe queries, runs anywhere
Auth + access
Clerk or NextAuth v5
Whichever fits your existing setup; both portable
Background jobs
Inngest
Replaces Bubble scheduling; durable, observable, retryable
Hosting
Vercel + Supabase
Default to portable infra; we can deploy to your AWS / GCP if you prefer
Source
Your GitHub org · day one
We push as collaborators on your repo. You own everything from commit 1.
How we approach a rebuild
Eight-step plan we follow on every migration. You decide which steps to skip.
Step 01
Day 0 · free
Audit + data-model export
We point our analysis pipeline at your export and read every workflow, every data type, every plugin. You get the McKinsey-grade report + a personalised tailwind.config.js extracted from your design system + a live preview deployed to Vercel — all before any commercial conversation.
- Pure read · we never write to your Bubble app
- Anonymised and deletable on request
- AI-generated, you keep the file rights
Step 02
Week 1
Schema migration · Postgres + Drizzle
We rebuild your Bubble data model 1:1 in Postgres with Drizzle migrations. Foreign keys, indices, and the privacy rules that survived translation are documented. Old Bubble row IDs are preserved as columns so we can dual-write during cutover.
- Schema migrations checked into Git
- Type-safe queries via Drizzle's inferred types
- RLS policies translated to Postgres row-level security
Step 03
Week 1
Auth bridge
Bubble doesn't let us export password hashes. We use Clerk or NextAuth v5 with one-time-passcode + magic link as the migration path — your users reset on first login or stay logged in via session token. No 'silent' rebuild user reset.
- Magic-link / OTP for migrated users
- Session continuity via signed JWT bridge
- SSO / SAML possible on enterprise
Step 04
Weeks 2-3
Spine workflows on code
The 5-10 workflows that ARE your product — billing, message send, content publish, whatever moves revenue. Each ships as its own PR with its own demo loom. Inngest replaces Bubble scheduling for cron + long-running tasks (no 300-second timeout).
- Each spine workflow has a real integration test
- Inngest dashboard exposes every run
- Idempotency keys on every external call
Step 05
Weeks 3-5
Dual-write data
Once spine workflows are stable on code, we start writing every mutation to BOTH Bubble (read-only sync) and Postgres. This lets you A/B test, fall back instantly, and prove parity before cutover.
- Bubble app stays the source of truth until cutover
- Daily reconciliation reports on dual-written records
- Rollback = revert one DNS change
Step 06
Weeks 3-5 (parallel)
UI port
Long tail of pages — most are variations of a pattern, not net-new. We batch by similarity (all list-with-filter pages together, all edit-record forms together) so each batch ships in days. Tailwind config is seeded from your existing palette so brand survives.
- Lighthouse performance check on every PR
- Accessibility scoreboard in CI
- Visual diff against the live Bubble page
Step 07
Final week
Cutover · 30-minute window
DNS flip + Bubble app frozen in read-only. We've been dual-writing for 2+ weeks so cutover is a 30-min window with active monitoring on a call. Bubble app stays read-only for 30 days as a fallback you can revert to in 2 minutes.
- Cutover runbook documented + rehearsed twice
- Two-engineer sign-off before DNS flip
- 30-day rollback plan with one DNS change
Step 08
After cutover
30-day warranty
We're on-call for any production issue 30 days post-cutover at no extra cost. Daily Slack standup, 3am pager rotation if needed. After 30 days you keep everything; we're an email away if you want us back.
- Critical paths have runbooks
- Sentry + Vercel observability handed over
- On-call schedule shared during handoff
Hybrid · the middle path
Customer-facing on code, admin tools on Bubble.
The default play for production teams. Hot paths (signup, billing, spine workflows, public pages) move to code where SOC2, performance and hiring matter. Cold paths (admin dashboards, internal CRM, one-off ops tools) stay on Bubble. We’ll score every page on the call and tell you which side it belongs.
- Half the rebuild cost vs full migration
- Half the cutover risk
- All the perf / hiring / diligence wins where they matter
- You can finish the migration later (or never)
What we don’t touch
Things we explicitly refuse to do.
Same energy as the "migrate now if / stay on Bubble if" line on the main page. Credibility-by-refusal.
- Visual redesigns. We preserve your existing UI language; if you want a redesign, hire a designer first.
- Building features you didn't have on Bubble. The rebuild ships parity; net-new work is a phase 2 conversation.
- Locking you to our hosting. Default is Vercel + Supabase; we'll deploy to your AWS / GCP if you'd rather.
- Trash-talking your Bubble dev's choices. The Bubble app shipped the business; we extend it, we don't shame it.
Want to pressure-test this against your app?
30 minutes with Greg · no slides, no pitch. Open your repo on screen, walk through the architecture, ask anything. If we’d build it differently than you would, you’ll know in 5 minutes.