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.
Want the diagnostic first? Why your Bubble app feels broken documents the 6 specific things that break in every production app; the WU calculator puts a number on the cost of staying. The design-system extractor post is the deepest technical write-up we’ve shipped publicly.
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.
CTO-shaped FAQ
The architectural questions that come up on every kickoff call.
Concrete answers — stack choice, migration mechanics, ownership, hybrid path, hiring market. If something here doesn't match how you'd build it, push back on the call.
- What stack do you rebuild Bubble apps on?
- Next.js 16 (App Router, React 19, TypeScript strict) for the application layer; Postgres with Drizzle ORM for the data layer; Clerk or NextAuth v5 for auth (whichever fits the existing setup); Inngest for background jobs and scheduled tasks; Tailwind CSS for styling; Vercel + Supabase as the default hosting (we can deploy to your AWS or GCP if you prefer). Every choice optimises for hireability — a senior engineer at any salary band should be able to ship within a week of joining.
- How do you handle the data migration from Bubble?
- We rebuild your Bubble data model 1:1 in Postgres with Drizzle migrations, preserving Bubble row IDs as a column so we can dual-write during cutover. Schema migrations are checked into Git, foreign keys and indices documented, and Bubble's privacy rules translated to Postgres row-level security policies where they survive translation. We never write to your Bubble app during migration — it stays the source of truth until cutover.
- Who owns the code after the rebuild?
- You do, from day one. We push as collaborators on your GitHub org — your repo, your CI, your staging, your runbook. The day we stop, you keep everything: source, infrastructure, observability, and the 30-day post-cutover documentation. No proprietary frameworks, no lock-in templates, no licensed components. Zero lock-in by design.
- Can we keep parts of our Bubble app and rebuild the rest?
- Yes — the hybrid path is the default for production teams. We move hot paths (signup, billing, spine workflows, public pages) to code where SOC 2, performance, and hiring matter; cold paths (admin dashboards, internal CRM, one-off ops tools) stay on Bubble. It costs roughly half a full migration, carries half the cutover risk, and you can finish the migration later or never. We score every page on the scoping call so you know which side each one belongs.
- How long does a Bubble-to-code rebuild actually take?
- Simple apps (1–2 weeks at $8–15k), medium (3–5 weeks at $18–32k), complex (6–10 weeks at $40–75k). Most production Bubble apps land in the medium tier. Cutover itself is a 30-minute window after 2+ weeks of dual-writing data so you can prove parity before flipping DNS. The Bubble app stays read-only for 30 days as a fallback. You see live deploys daily from week one — not a six-week black box.
- What about hiring engineers after we leave Bubble?
- That's the main reason for the stack choice. Next.js + TypeScript + Postgres is the most common modern web stack on the market — every senior full-stack candidate has shipped on it. Compared to Bubble (where there's no engineering labour market — Bubble devs are platform specialists), code gives you access to every engineer at every salary band. We document the codebase with a runbook and onboarding notes so the first hire ships in their first week.
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.