Builder.ai Stranded? The Complete Migration Guide (2026)
In May 2025, Builder.ai — once valued at $1.3 billion — collapsed into insolvency. Thousands of small businesses lost access to apps they had paid tens of thousands of pounds to build. If you are one of them, this guide gives you a clear, honest path forward: what you can recover, where to migrate, and how to get your app working again.
Are you a Builder.ai customer right now?
We assess your situation in 24 hours and give you a concrete recovery plan — free.
Quick triage: what is your situation?
Before diving into the full guide, find your row in the table below. Each situation calls for a different first move.
| Your situation | Urgency | First move | Read section |
|---|---|---|---|
| App is live but could go dark any day | Critical | Export all data NOW, screenshot every screen, document your DNS settings | Section 4 |
| App went dark, no access to dashboard | High | Attempt administrator contact, check for any local/emailed assets | Section 3 |
| Project was in build - never launched | Medium | Retrieve any design files / specs. Choose a new platform to restart. | Section 5 |
| App is down and you have business-critical data trapped | Critical | Contact UK insolvency administrator + seek legal advice immediately | Section 10 |
| App is down but you have a backup / old codebase | Lower | You are in the best position. Pick a target stack and migrate systematically. | Section 6 |
| You lost money and want to explore claims | Situational | File a creditor claim with the UK administrator. Consult a solicitor. | Section 10 |
What happened to Builder.ai
Builder.ai (formerly Engineer.ai) was a London-based startup that promised businesses they could describe an app in plain English and have it built automatically by AI. The company raised approximately $450 million from investors including Microsoft, the Qatar Investment Authority, and others. At its peak it was valued at more than $1.3 billion.
The collapse came in stages. In early 2025, Bloomberg and other outlets reported that Builder.ai had allegedly overstated its revenue by more than $100 million. Shortly after, Israeli lending firm Viola Credit seized most of the company's cash under the terms of a debt facility. With liquidity gone, Builder.ai entered formal insolvency proceedings in the UK on approximately May 20, 2025, appointing a court-approved administrator.
The underlying product controversy: Builder.ai marketed its “Natasha” AI as an automated app-building engine. Investigations by Rest of World and other journalists found that the vast majority of actual development work was performed by human contractors — reportedly around 700 engineers, many in India — with the AI handling at most routine template-matching tasks. This was not disclosed to customers in a meaningful way.
Note on allegations vs. verified facts
Revenue misrepresentation allegations are based on published reporting (Bloomberg, May 2025). The UK insolvency proceedings are a verified public record. The “700 engineers” figure comes from reporting by Rest of World citing multiple former employees. No criminal charges had been confirmed publicly as of this writing. Customers should base their decisions on the verified fact of insolvency, not speculation.
What matters practically: the company is in administration, its servers may be decommissioned, and there is no normal customer support channel. Whatever you can do to recover assets needs to happen quickly.
What you can actually recover from Builder.ai
The hard truth first: Builder.ai used a proprietary platform. Most customers did not receive a Git repository or deployable codebase as part of the engagement. That said, the picture is not uniformly bleak. Here is what may be recoverable, in order of likelihood:
Your data (if the dashboard is still accessible)
Log in now. Export every table, every customer record, every transaction log as CSV or through any available API. Data is often the most valuable part of what you built — do not lose it.
Design assets and specifications
Check your email history with Builder.ai for any attached Figma files, wireframes, PDFs, or specification documents. These may have been shared during the project. They are owned by you and are enormously useful for rebuilding.
Your domain and DNS settings
If your custom domain was registered through Builder.ai, you need to regain control immediately. Check your registrar account (GoDaddy, Namecheap, Google Domains). If Builder.ai registered it on your behalf, contact the insolvency administrator with proof of ownership and payment.
Source code (limited, but worth checking)
Some Builder.ai projects included a Git repository link in project documentation. Check all emails and project portal exports for any GitHub or GitLab URLs. If a developer was assigned to your project, they may still have a local copy — contact anyone you have a name for. Under UK insolvency law, IP you paid to create may be claimable from the administrator (see Section 10).
The platform itself — very unlikely
Builder.ai's platform infrastructure is controlled by the administrator. Unless a buyer acquires the business as a going concern, the platform will be wound down. Do not wait for this outcome.
How to extract your data right now
Time-sensitive: the Builder.ai portal may be accessible on some days and not others as administrators manage server costs. Do this today if you have not already.
Step A: Screenshot and record every screen
Use a tool like Screenpresso or the browser extension Full Page Screen Capture to take full-page screenshots of every view in your app: dashboard, forms, user flows, admin panels. These become your rebuild blueprint.
Step B: Export data via the dashboard
In the Builder.ai project portal, look for any “Export” or “Download” options in data tables, CRM views, and reporting sections. Export as CSV. Even if the format is messy, raw data is salvageable.
Step C: Try the Builder.ai API (if your plan included API access)
Some Builder.ai tiers exposed a REST API. If you have an API key in your account settings, try pulling your data programmatically before the endpoints go offline. A minimal Node.js script to test access:
// test-builder-export.js
// Run with: node test-builder-export.js
// Replace YOUR_API_KEY and YOUR_PROJECT_ID
const BASE_URL = 'https://api.builder.ai/v1';
const API_KEY = 'YOUR_API_KEY';
const PROJECT = 'YOUR_PROJECT_ID';
async function tryExport() {
try {
const res = await fetch(`${BASE_URL}/projects/${PROJECT}/data`, {
headers: { 'Authorization': `Bearer ${API_KEY}` }
});
if (res.ok) {
const data = await res.json();
require('fs').writeFileSync(
`builder-export-${Date.now()}.json`,
JSON.stringify(data, null, 2)
);
console.log('Export saved.');
} else {
console.log(`API returned ${res.status} - endpoint may be offline.`);
}
} catch (err) {
console.log('Connection failed:', err.message);
}
}
tryExport();
Note: This script tests whether Builder.ai's API is still responding. If it returns a 404 or connection error, the endpoint is likely down. This is a diagnostic, not a guaranteed export path.
Step D: Contact the insolvency administrator
Builder.ai's UK insolvency is administered by a court-appointed firm. Search Companies House (beta.companieshouse.gov.uk) for “Builder.ai” to find the appointed administrator's name and contact details. Write a formal letter stating your customer status, the IP you paid to create, and requesting access to your project assets. Attach your original contract, invoices, and any project delivery receipts. This is a legitimate creditor action under UK insolvency law.
Migration paths: where to go next
Where you migrate depends on three factors: how technical your team is, how complex your app is, and how much ongoing maintenance flexibility you need. The table below maps common situations to recommended stacks.
| Platform / Stack | Best for | Code ownership | Technical level needed | Approx. monthly cost | AppStuck page |
|---|---|---|---|---|---|
| Lovable | Non-technical founders, simple to medium apps | Full (GitHub sync) | None | $25–$50/mo | View |
| Bolt.new | Fast rebuilds from spec or screenshots | Full (GitHub sync) | None | $20/mo | View |
| Next.js + Supabase | Complex apps needing custom logic | Full | Medium–High | $0–$25/mo infra | View all |
| React Native + Expo | Mobile-first apps (iOS/Android) | Full | Medium–High | $0–$25/mo infra | View all |
| Cursor | Teams with a developer wanting AI-assisted coding | Full | Medium | $20/mo + hosting | View |
| Shopify | E-commerce apps specifically | Partial (Shopify-hosted) | Low | $39–$399/mo | — |
Step-by-step migration playbook
Audit your existing Builder.ai project
Before anything else, document everything. This audit becomes the foundation of your migration and your brief for any developer you hire.
Actions
- Screenshot every screen in the app
- Export every data table you can access
- Record your domain and DNS settings
- Document every third-party integration
- Save all API keys you control
- Download all design files from your email history
Tools
- Screenpresso or Full Page Capture (browser extension)
- Google Drive or Dropbox to organise everything
- Loom to record user walkthroughs
Estimates and pitfalls
Time: 2–8 hours
Pitfall: Waiting until the platform goes completely offline. Act now — the Builder.ai portal is accessible intermittently and data loss is permanent.
Reverse-engineer the spec
Reconstruct a functional specification from your screenshots, audit notes, and memory of how the app worked. This document is the single most valuable thing you can produce at this stage.
Actions
- List every user role (admin, customer, staff)
- For each role, list every action they can take
- Document every data object the app stores
- Map every screen to its user journey
- Note every third-party service (payments, email, auth)
Tools
- Notion or Google Docs for the spec
- Figma for annotating screenshots
- Miro or Whimsical for user flow diagrams
Estimates and pitfalls
Time: 4–16 hours
Pitfall: Skipping this step and going straight to rebuilding. Any developer — human or AI — will produce better results from a clear spec than from vague verbal descriptions.
Choose your target stack
Evaluate platforms based on code ownership, scalability, and your team's technical level. The wrong choice here creates new lock-in risk. Prioritise platforms that give you a fully exportable, runnable codebase.
For apps needing custom logic
Next.js + Supabase, built with Cursor or a professional developer. Maximum flexibility, full ownership.
For mobile-first apps
React Native + Expo + Supabase. Cross-platform iOS and Android from a single codebase, deployable to both App Stores.
Re-implement on the new stack
Build against your spec, not your memory of the old app. Start with the critical path — the 20% of features that 80% of your users need every day. Get that working and deployed first. You can layer in secondary features over subsequent weeks.
Actions
- Set up a staging environment first
- Implement authentication and user roles
- Build data models matching your spec
- Implement each feature in priority order
- Test every flow before calling it done
Tools
- Lovable, Bolt.new, or Cursor (per Step 3 decision)
- Supabase or Firebase for database + auth
- Vercel or Netlify for hosting
- GitHub for version control
Estimates and pitfalls
Time: 1–8 weeks depending on complexity
Pitfall: Trying to rebuild everything at once before getting any version live. Ship the critical path, get feedback, then iterate.
Migrate your data
Data migration is where migrations fail silently. A record count mismatch or malformed date field can corrupt your new system weeks after go-live. Be methodical.
Actions
- Clean and deduplicate exported CSV data
- Map old field names to new schema fields
- Write an import script (Node.js or Python)
- Run import on staging first
- Validate: count records, spot-check 20 rows, check nulls
- Only then run on production
Tools
- Python pandas for data cleaning
- Supabase or Firebase import CLI
- TablePlus or DataGrip for manual inspection
Estimates and pitfalls
Time: 4–24 hours
Pitfall: Importing without validating. Run the import in staging, run a row-count SQL query, and manually check at least 20 records before touching production.
# validate-import.py
import pandas as pd
from supabase import create_client
SUPABASE_URL = "YOUR_SUPABASE_URL"
SUPABASE_KEY = "YOUR_SUPABASE_ANON_KEY"
TABLE = "your_table_name"
ORIGINAL_CSV = "builder-export.csv"
client = create_client(SUPABASE_URL, SUPABASE_KEY)
original = pd.read_csv(ORIGINAL_CSV)
print(f"Source rows: {len(original)}")
response = client.table(TABLE).select("id", count="exact").execute()
print(f"Destination rows: {response.count}")
if len(original) == response.count:
print("Row counts match. Spot-check 20 records manually.")
else:
print(f"MISMATCH: {len(original) - response.count} rows missing.")
Go live
Actions
- Point your domain DNS to the new host
- Set up SSL certificate (automatic on Vercel/Netlify)
- Run a final smoke test on all critical flows
- Notify users of the new URL if it changed
- Set up monitoring (UptimeRobot, free tier)
- Archive all Builder.ai-related accounts
Tools
- Your domain registrar DNS panel
- Vercel / Netlify for deploy
- UptimeRobot (free) for uptime monitoring
- Google Search Console to reindex new URLs
Estimates and pitfalls
Time: 2–4 hours
Pitfall: Forgetting to redirect old URLs. If your Builder.ai app had public-facing URLs indexed by Google, set up 301 redirects to the equivalent new pages or you lose organic traffic permanently.
AppStuck Rescue Service
Don’t want to do this alone?
We have rescued 300+ apps — including several Builder.ai projects. We can audit what you have, reverse-engineer your spec, and migrate you to a stack you own. Typical turnaround: 2–6 weeks. Free assessment within 24 hours.
Common scenarios with solutions
The right migration path depends heavily on what kind of app you had. Here are the four most common Builder.ai customer types and the recommended approach for each.
| App type | Typical features | Recommended target stack | Rebuild time estimate | Key risk |
|---|---|---|---|---|
| E-commerce | Product catalogue, cart, payments, order management | Shopify (simplest) or Next.js + Stripe | 1–3 weeks | Customer order history data loss |
| Internal tool / dashboard | Tables, forms, reporting, role-based access | Lovable or Retool | 1–2 weeks | Permission logic complexity |
| Mobile app (iOS/Android) | Native UI, push notifications, device features | React Native + Expo + Supabase | 4–10 weeks | App Store re-submission time (2–7 days) |
| SaaS / multi-tenant | Multiple customer accounts, billing, API, webhooks | Next.js + Supabase + Stripe (built with Cursor) | 6–16 weeks | Multi-tenant data isolation — must be correct from day one |
What it costs and how long it takes
These are realistic ranges based on typical migration and rebuild projects. Costs assume you are hiring an experienced developer or agency. DIY with AI tools (Lovable, Bolt) reduces cost significantly but increases your time investment.
All figures are estimates. Actual costs depend on app complexity, data volume, and chosen stack. AppStuck provides fixed-price quotes after a free assessment.
| Project size | App complexity | DIY cost (tools only) | Agency / dev cost | Timeline |
|---|---|---|---|---|
| Small | Simple forms, static content, basic CRUD | $20–100 | $2,000–6,000 | 1–2 weeks |
| Medium | User auth, payments, multiple roles, 5–20 screens | $50–200/mo platform | $6,000–18,000 | 3–6 weeks |
| Large | Multi-tenant SaaS, mobile, 20+ screens, APIs | Not recommended | $18,000–50,000+ | 8–20 weeks |
| Emergency (app down, revenue at risk) | Any — critical path only to restore revenue | N/A | $3,000–10,000 (MVP) | 5–14 days |
For reference: Builder.ai customers typically paid anywhere from a few thousand pounds (Studio Store plans at roughly GBP 75/month over 24 months) to tens of thousands for custom builds. A migration to an owned stack at these prices is often less than what was originally paid to Builder.ai.
Red flags: mistakes to avoid when migrating
Choosing another platform with the same lock-in risks
Any platform that does not give you exportable, runnable code puts you in the same position as Builder.ai. Always verify code export before committing. Read our Builder.ai platform page for a breakdown of what made it risky.
Rebuilding all features before validating the migration works
Ship a working critical path first. Getting your app live — even with 60% of features — restores business continuity. Secondary features can follow.
Migrating without a staging environment
Never run a first data migration directly to production. Test everything in staging with a copy of the data. This rule saves you every time.
Hiring the cheapest developer you can find on Fiverr
Migrations done cheaply tend to leave technical debt that costs 3–5x to fix later. Verify the developer has experience with your target stack and ask for references from migration projects specifically.
Ignoring SEO redirects
If your Builder.ai app had indexed pages (common for e-commerce or content apps), failing to set up 301 redirects to equivalent new URLs will destroy any search ranking you had built. Set up redirects on day one of the new deployment.
Waiting to see if Builder.ai will come back
The company entered formal insolvency. The probability of a return to normal service is very low. Every week of waiting is a week of business disruption and a week your data sits on servers with no guaranteed uptime.
Legal considerations for Builder.ai customers
This section is general information, not legal advice. Consult a qualified solicitor for advice specific to your situation.
IP ownership: what does your contract say?
Builder.ai's standard contracts typically assigned intellectual property to the customer upon full payment. If you paid in full and have a contract clause confirming IP transfer, you have a documented claim to your source code. Locate your original contract and find the IP ownership clause before contacting the administrator.
Filing a creditor claim
As a customer who paid for services not fully delivered, you may have standing as an unsecured creditor in the UK insolvency process. Typical steps:
- Search Companies House for the appointed administrator's details (beta.companieshouse.gov.uk, search “Builder.ai Limited”).
- Submit a formal Proof of Debt form to the administrator with your contract, invoices, and a statement of what was not delivered.
- Be realistic: unsecured creditors typically recover a small fraction (often 0–20 pence per pound) in insolvency proceedings, and it can take 12–24 months.
Insurance claims
Some businesses hold trade credit insurance or business interruption insurance that may cover losses from a key supplier's insolvency. Review your business insurance policy and contact your broker to check coverage.
GDPR and data protection obligations
If your Builder.ai app stored personal data about your customers (names, emails, purchase history), you retain data controller obligations under GDPR even though Builder.ai — as data processor — has ceased operations. You should notify your users if their data may be at risk, document the incident, and retrieve and secure user data before servers go offline.
Chargebacks (for recent payments)
If you made a payment to Builder.ai in the 60–120 days prior to the insolvency, you may be able to raise a chargeback with your credit card provider for services not rendered. Act quickly — chargeback windows are typically 60–120 days from the transaction date, depending on your card network.
Frequently asked questions
Is Builder.ai completely shut down?+
Can I get my source code back from Builder.ai?+
How long does a Builder.ai migration take?+
What are the best Builder.ai alternatives in 2026?+
Will Builder.ai refund customers?+
Can I migrate without a developer?+
What happened to my data stored in Builder.ai?+
Is this the same Builder.ai that Microsoft invested in?+
How do I avoid this happening again with my next platform?+
Does AppStuck work with Builder.ai migrations specifically?+
When to call an expert
The playbook in this guide is designed to be actionable without outside help for simple apps. But there are situations where trying to DIY will cost you more time and money than hiring an expert from day one:
Call an expert if:
- Your app handles payments or financial data
- Your app serves active customers and downtime is costing you revenue right now
- Your app has complex multi-role permissions
- You have no technical background and your app is more than a simple form or booking page
- Your app has significant data (thousands of records) that must migrate without errors
- You need the migration done in under 2 weeks
- Your app is a mobile app on the App Store or Google Play
DIY is viable if:
- Your app is a landing page, simple booking form, or basic CRUD tool
- You have 4–8 weeks and can afford to learn as you go
- You are comfortable using Lovable or Bolt.new
- Your data is limited and clean (under 5,000 records)
- You have no external users depending on the app right now
AppStuck's AI app rescue service is built specifically for situations like Builder.ai migrations. We have handled rescues with no source code, with partial codebases, with live user bases, and with tight deadlines. See the Builder.ai platform page for more context on what we typically find in these projects.
Related resources
AppStuck — AI App Rescue
Ready to get your app back?
Soren and the AppStuck team have rescued 300+ apps since 2009. We will assess your Builder.ai project, tell you exactly what is recoverable, and give you a fixed-price migration plan — free, within 24 hours.
Book a Free Discovery CallNo commitment. 24-hour response. Fixed prices, no surprises.
Need Help with Your AI Project?
If you're dealing with a stuck AI-generated project, we're here to help. Get your free consultation today.
Get Free Consultation