Migration snapshot
ActivePlatform
a Stacker
Rebranded to Stacker AI (stacker.ai) in late 2025; relaunched as an AI-native platform for internal tools, CRMs, and dashboards. GA in 2026. Raised ~$23M total including $20M Series A led by Andreessen Horowitz (Aug 18, 2021). Niche player facing pressure from Softr, Noloco, and Glide; direction risk is real but no shutdown signals.
Typical timeline
6–10 weeks
Typical cost
$13K–$25K (agency, fixed)
Why teams leave a Stacker
Stacker is a fast portal builder for data you already own in Airtable or Google Sheets. Migration makes sense when you need custom UI, a real backend, or when per-seat pricing math no longer adds up.
Pricing escalation
Plus plan ~$199/mo, Pro ~$349/mo (hackceleration.com, 2026 — verify against official pricing before citing). Reviewers note that 'a lot of what should be basic requires the highest plan' (getapp.com), pushing teams to upper tiers faster than expected.
Design ceiling
Stacker's opinionated grid layout offers limited branding and customization compared to Bubble or WeWeb. When UI requirements surface mid-project — bespoke portal branding, custom components — teams quickly hit a ceiling with no escape hatch.
No code exit
There is zero source-code export. Leaving Stacker means a complete rebuild of the portal layer. Data in Airtable or Sheets is yours and portable; the app itself is not.
No native mobile
Stacker is portals and internal tools only — there is no app-store publishing path and no mobile parity option. Teams that eventually need iOS/Android must rebuild elsewhere entirely.
Backend dependency ceiling
Stacker is a presentation layer over Airtable/Sheets/Salesforce. Any need for a real relational backend, custom API, webhooks, or HIPAA compliance forces a move to Retool, Xano, or a code-based stack.
What can you actually take with you?
Your data is fully portable because it lives in Airtable or Google Sheets — not in Stacker. The portal app itself (code, UI, logic, permissions) cannot be exported in any form.
| Asset | Can you export it? | How | Notes |
|---|---|---|---|
| Data | Yes | Export directly from Airtable (CSV per table) or Google Sheets — Stacker is not the data store | Stacker's own portal configuration and computed row-level permission logic are not exportable; export your underlying data sources, not Stacker itself |
| Code | No | No source-code export exists | Full rebuild of the app layer is required on exit; no partial export, no component download |
| Design/UI | No | Not exportable | Opinionated grid UI; no design file, no component export; screenshot every view before migration |
| Logic/Workflows | No | Not exportable | Permission rules, row-level filtering, and portal logic must be reconstructed from screenshots and documentation |
| Users & Auth | Partial | Portal user accounts managed in Stacker; export mechanism not documented | Password hash export not documented; plan forced password reset at cutover; SSO-connected users depend on your identity provider and can be rewired |
| Integrations/SSO | Partial | SAML/OIDC provider configuration is external to Stacker | Your SSO provider (Okta, Azure AD, Google Workspace) is portable and can be rewired to the new app; Stacker-specific integration config is lost |
Swipe the table sideways to see the full breakdown.
Where each piece moves in code
Stacker portal features map to a Next.js App Router frontend with Supabase PostgreSQL replacing Airtable as the backend database.
a Stacker
Airtable/Sheets data source
In code
Supabase PostgreSQL tables
Migrate via CSV export from Airtable → Supabase Table Editor import or migration script
a Stacker
Stacker portal page
In code
Next.js App Router page with Server Component data fetch
Each portal view becomes a typed Server Component querying Supabase with RLS
a Stacker
Stacker record view / form
In code
React form component + Supabase RLS policy
Read/write access enforced by Supabase row-level security instead of Stacker field rules
a Stacker
Stacker row-level permissions
In code
Supabase RLS policies per authenticated user role
Every Stacker permission rule must be re-implemented as a RLS policy and audited before go-live
a Stacker
Stacker field visibility rules
In code
Conditional rendering in React components + server-side filtering
Field visibility logic moves to TypeScript conditionals; server-side filtering prevents data leakage
a Stacker
Stacker user portal accounts
In code
Supabase Auth (email/password or SSO via OAuth)
Portal users must re-register or be bulk-imported; SSO via OAuth2/OIDC can be rewired to same provider
a Stacker
Stacker custom domain
In code
Vercel custom domain on Next.js deployment
DNS CNAME switch at cutover; same domain reusable
a Stacker
Stacker AI prompt-to-app
In code
Lovable or V0 as scaffolding, then custom code
No automated import path from Stacker AI output; use AI tools to accelerate greenfield rebuild
The migration roadmap
Migration is a full rebuild — there is no code to port. The roadmap starts with visual documentation (screenshots, permission notes) because Stacker has no config export.
Extraction & Documentation
Week 1- Export every Airtable/Sheets base connected to Stacker as CSV
- Screenshot every portal view, record detail page, and form layout
- Document every role, permission rule, and field visibility setting per user type
- List all portal user accounts and roles (export from Stacker admin if available)
- Identify SSO provider(s) so auth can be rewired to the new app
Watch out: Stacker has no config export — screenshots and notes are the migration blueprint; be thorough now to avoid guessing later
Foundation & Data Migration
Weeks 2–3- Set up Next.js App Router project on Vercel with Supabase backend
- Define Supabase schema matching Airtable field structure (types, relations)
- Import CSV exports into Supabase tables and verify row counts
- Implement Supabase Auth with the same SSO provider(s) used in Stacker
- Freeze Airtable schema changes during migration sprint
Watch out: Any Airtable schema change mid-migration breaks the imported data; notify the team and lock the base
Portal Rebuild
Weeks 3–7- Implement Supabase RLS policies for every documented Stacker permission rule
- Build portal pages as Next.js Server Components with Supabase data fetch
- Implement record views, forms, and field visibility logic in React
- Add search, filtering, and related-record UI (plan 1–2 extra sprints for this)
- Conduct RLS audit: verify no unauthorized data is accessible before go-live
Auth Migration & Cutover
Weeks 8–10- Prepare magic-link invite campaign for all portal users (no password migration possible)
- Run parallel testing period with subset of users on new app
- Switch DNS/custom domain to new Vercel deployment
- Send re-registration invites to all portal users with a 2-week window
- Monitor for permission errors and missing data in first two weeks
Three ways to migrate — honestly
Every path has a real trade-off. Here is what each costs, how long it takes, and where it bites.
DIY (with AI tools)
$0–500 + time
3–6 months part-time
Fits
Technical founder comfortable with Next.js and Supabase; simple portal with 2–3 views and basic RLS
Risks
Permission re-implementation is error-prone without a review process; user re-registration timing requires careful planning; easy to underestimate RLS audit scope
Freelancer
$3K–10K
6–10 weeks
Fits
Small portal with moderate complexity; freelancer with Next.js + Supabase RLS experience; clear requirements from the screenshot documentation phase
Risks
No built-in QA process for RLS audit; single point of failure; user migration campaign needs coordinating separately
Agency (RapidDev)
Done-for-you$13K–25K fixed
6–10 weeks
Fits
Multi-role portals with complex permission matrices; team needing RLS audit, user migration, and SSO rewiring; prefer fixed-price scope clarity
Risks
Highest upfront cost; justified by permission complexity and the forensic documentation work Stacker requires on exit
The real risks — and how to defuse them
Permissions gap
Mitigation: Stacker's row-level and field-level permission rules must be manually re-implemented as Supabase RLS policies; untested policies can expose data — conduct a dedicated RLS audit before go-live
User re-registration
Mitigation: Portal users cannot be migrated with passwords; prepare a magic-link invite flow at cutover and give users a 2-week window to re-register before closing the old portal
Airtable schema disruption
Mitigation: Airtable is the live data source during migration; any schema change mid-sprint breaks the import — freeze Airtable schema during the final migration sprint and notify all editors
Feature parity gap on search and filters
Mitigation: Stacker's instant search, multi-field filters, and related-record UI take longer to rebuild than estimated; plan a phased cutover — launch with core views first, then add advanced search in a second release
Pricing source reliability
Mitigation: Stacker Plus ~$199/mo cited from hackceleration.com (2026) — verify directly on stacker.ai before using in any cost-benefit analysis; third-party pricing data can lag official changes
Should you actually migrate?
Migrating is a real project. Sometimes staying is the right call — here is the honest split.
Stay if
- Your app is genuinely a simple internal portal over Airtable/Sheets and the team has no developer resources — Stacker AI builds working portals in 3–5 minutes and the permissions model is strong
- You need fine-grained external data sharing (client portals, partner access) and the current UI is acceptable; Stacker's per-row permission model is a genuine differentiator for this use case
- The $199+/mo cost is well within budget and you don't need native mobile, custom UI, or a real API backend
Migrate if
- You've hit the design customization ceiling and need branded, bespoke UI that Stacker's grid layout cannot deliver
- You need a real backend — custom API endpoints, complex joins, webhooks, HIPAA compliance — Stacker explicitly doesn't offer this
- Per-seat or tier pricing is growing faster than the app's value; owning the code gives flat infrastructure cost instead of escalating SaaS fees
Our honest verdict
Stacker earns its keep as a fast portal builder for data you already own in Airtable. Migrate when you need real UI control, a real backend, or the math on seats vs infrastructure cost flips.
Do this today: pre-migration checklist
Whatever path you choose, protect yourself first. Work through this before you touch a line of code.
Export every Airtable/Sheets base connected to Stacker as CSV today
Your data is in Airtable, not Stacker — this is the most portable asset and takes minutes
Screenshot all portal views, record detail pages, and form layouts
Stacker has no config export; screenshots are the migration blueprint for rebuilding the UI
Document every role, permission rule, and field visibility setting per user type
Stacker permission logic must be manually reconstructed as Supabase RLS policies — thorough notes now prevent security gaps later
List all portal user accounts and their roles (export from Stacker admin if available)
You'll need this list for the magic-link re-registration campaign at cutover
Identify SSO provider(s) so auth can be rewired to the new app
SAML/OIDC providers are portable; knowing which ones are in use lets you rewire auth without forcing re-registration for SSO users
Confirm and freeze the Airtable field schema before the migration sprint begins
Schema changes during migration break CSV imports and data mapping; lock the base for the duration of the final sprint
Frequently asked questions
Can I export my Stacker app code?
No. Stacker has zero source-code export of any kind. Leaving Stacker requires a complete rebuild of the portal layer. The good news: your data is not in Stacker — it lives in your Airtable base or Google Sheets, which you can export as CSV at any time.
Is Stacker shutting down?
No. As of 2026, Stacker is operating and repositioning as Stacker AI. The platform raised ~$23M total including a $20M Series A led by Andreessen Horowitz. There are no shutdown signals, though it is a niche player in a competitive market.
How long does a Stacker migration take?
Typically 6–10 weeks with a dedicated team. The timeline is dominated by rebuilding the portal UI and permission logic in Next.js + Supabase, not data migration (which is fast since data is in Airtable). Complex multi-role permission matrices add time.
What happens to my portal users and passwords during migration?
Portal user passwords cannot be migrated — there is no documented password hash export from Stacker. Plan a magic-link invite flow at cutover. SSO-connected users (SAML/OIDC) can often be re-connected to the same identity provider without needing to re-register.
Do I need to rebuild my Airtable data?
No. Export your Airtable base as CSV tables, then import those CSVs into Supabase PostgreSQL. The data migration is straightforward; the rebuild effort is entirely in recreating the portal UI and permission rules that Stacker was managing.
What is the cost to migrate from Stacker?
DIY with AI tools: $0–500 plus significant time (3–6 months part-time). A Freelancer: $3K–10K over 6–10 weeks. An agency like RapidDev offers fixed-price migrations at $13K–25K completed in 6–10 weeks, which includes the RLS audit, user migration campaign, and SSO rewiring.
Is the Stacker Plus plan really $199/mo?
Pricing of ~$199/mo for Plus and ~$349/mo for Pro was cited by hackceleration.com (2026). Always verify current pricing directly on stacker.ai — third-party sources can lag official changes, and Stacker has been updating its plans as part of the Stacker AI rebrand.
Should I stay on Stacker or migrate?
Stay if your portal is genuinely simple, backed by Airtable data you control, and the current UI meets your needs — Stacker's permission model is strong for client portals and partner access. Migrate when you need bespoke UI, a real API backend, HIPAA compliance, or when per-seat costs exceed infrastructure alternative costs.
We migrate no-code apps to production code
- Fixed price — $13K–$25K (agency, fixed)
- No data loss, no downtime
- You own 100% of the code
30-min call. Quote within 48 hours.
