Skip to content
ai architecture vendor-lock-in migration 12 min read

Your AI-Built App Is Hostage: How to Escape Platform Vendor Lock-in

Rachid Al Maach ·

You shipped your app in a weekend. An AI agent wrote the code, deployed it, gave you a URL. You showed it to customers. It worked. You felt like a genius.

Then the invoice arrived.

$200 a month. Not for hosting. Not for a database. For AI tokens. The agent that built your app is now running on every request, every change, every bug fix. Your "free" app has a subscription you never signed up for.

Welcome to AI platform vendor lock-in.

The trap

AI agent platforms like Manus, Lovable, Bolt, and others promise the same thing: describe your app, let the AI build it, ship it today. And they deliver. The app works. The landing page looks good. The forms submit.

What they don't tell you is what happens after launch.

Your code lives on their infrastructure. Every change routes through their AI agent, which burns tokens. Need to fix a typo on your homepage? That's an agent call. Need to add a new page? More tokens. Need to debug why a form stopped working? The agent rewrites half your codebase and charges you for the privilege.

You don't own a product. You rent one. And the landlord can raise the rent whenever they want.

Why this happens

AI platforms create dependency by design. Not because they're evil. Because their business model requires it. Here's what makes you stuck:

No standard deployment. Your code runs on their infrastructure. There's no Docker container you can download, no server you can point to, no deploy button that works anywhere else. If you leave, your app stops working.

AI agents run on every interaction. Unlike traditional hosting where your code runs on a server and that's it, these platforms route changes (and sometimes requests) through an AI agent. That means continuous token consumption. The meter never stops.

Generated code has no structure. The AI wrote code that works, but it has no tests, no documentation, no consistent architecture. It's a collection of files that happen to produce the right output. Try understanding it six months later.

Platform-specific abstractions. Many platforms wrap standard libraries in their own SDKs. Your "React app" actually depends on platform-specific components that don't exist anywhere else. Remove them and nothing renders.

No version control. There's no git history. No branches. No way to see what changed and when. If the agent breaks something, you can't roll back. You ask the agent to fix it, and it rewrites more code, and you burn more tokens.

The real cost

Let's do the math on a real scenario.

You built a membership site with an AI platform. Monthly costs:

  • AI token fees: $200-500/month (scales with usage and changes)
  • Platform subscription: $20-50/month
  • Every bug fix: 5-20 minutes of agent time, more tokens
  • Every feature request: even more tokens

The same app on a $10/month VPS with Docker: $10/month. No token fees. No per-change costs. You edit a file, push to git, it deploys. Done.

Over a year, the difference is $2,400-6,000 versus $120. And that's before counting the unpredictable spikes when the agent decides to "improve" your codebase.

But the cost that matters most isn't money. It's control. You can't switch hosting providers. You can't hire a developer to work on your code independently. You can't sell your app without selling the platform dependency with it. Your business is built on someone else's runtime.

The migration playbook

We migrated five production apps off an AI agent platform. Each one followed the same seven-step process. Here's the playbook.

Step 1: Export everything

Get your code out. Most platforms let you download source code, even if they make it hard to find. Download every file. Export your database. Save your environment variables. Screenshot your platform settings.

If the platform won't give you a database export, check if you can access the database directly. Many platforms use standard MySQL or PostgreSQL under the hood.

# Export from platform (if they even let you)
mysqldump -h platform-host -u user -p dbname > backup.sql

# Import to your own database
mysql -h localhost -u user -p myapp < backup.sql

Save your environment variables. Every secret, every API key, every configuration value. You'll need all of them.

# .env - your app's configuration
DATABASE_URL=mysql://user:pass@db:3306/myapp
AUTH_SECRET=your_jwt_secret_here
SMTP_HOST=smtp.sendgrid.net
SMTP_USER=apikey
SMTP_PASS=your_sendgrid_key
APP_URL=https://yourdomain.com

Step 2: Audit the codebase

Before you touch anything, read the code. All of it. You need to answer three questions:

  1. What actually works? Not what the agent said it built. What actually functions when you click through the app.
  2. What's platform-specific? Look for imports from the platform's SDK, API calls to their endpoints, components that only exist in their ecosystem.
  3. What's AI spaghetti? Code the agent rewrote three times. Dead functions. Unused files. Dependencies installed but never imported. Every AI-generated codebase has these. Identify them now.

Make a list. "Works and keep." "Works but needs platform references removed." "Delete." This audit saves you hours of confusion later.

Step 3: Set up real infrastructure

You need three things: a server, Docker, and a deployment pipeline.

A VPS from any provider works. Hetzner, DigitalOcean, Vultr. Pick one. Install Docker. Create a docker-compose file that describes your app and its database.

version: "3.8"
services:
  app:
    build: .
    ports:
      - "3000:3000"
    environment:
      - DATABASE_URL=mysql://user:pass@db:3306/myapp
      - NODE_ENV=production
    depends_on:
      - db

  db:
    image: mysql:8
    volumes:
      - db_data:/var/lib/mysql
    environment:
      - MYSQL_ROOT_PASSWORD=secure_password
      - MYSQL_DATABASE=myapp

volumes:
  db_data:

Create a Dockerfile for your application:

FROM node:20-alpine
WORKDIR /app
COPY package*.json ./
RUN npm ci --production
COPY . .
RUN npm run build
EXPOSE 3000
CMD ["node", "dist/index.js"]

This is your entire deployment story. No AI agents. No token consumption. Push code, build container, run it.

Step 4: Database migration

If you got a database export in Step 1, import it into your self-hosted database. Verify the data. Check that your tables, rows, and relationships are intact.

If the platform used a non-standard database or a proprietary data layer, you'll need to write a migration script. This is the hardest part. Some platforms store data in formats that don't map cleanly to standard databases. Budget extra time for this.

Step 5: Fix platform-specific code

This is where the audit from Step 2 pays off. Go through every platform-specific reference and replace it:

  • Platform SDK imports: Replace with standard libraries. If they used a custom auth wrapper, switch to a standard JWT library. If they used a proprietary database client, switch to a standard ORM.
  • Hardcoded platform URLs: Replace with environment variables pointing to your own domain.
  • Platform-specific components: Replace with standard React components, or whatever framework you're using. Most platform components are thin wrappers around standard ones.
  • Platform API calls: If your app called platform APIs for things like file storage or email, replace with direct integrations (S3, SendGrid, etc.).

Test each replacement individually. Don't try to swap everything at once.

Step 6: Deploy and verify

Deploy your containerized app to your VPS. Set up a reverse proxy to handle HTTPS:

server {
    listen 80;
    server_name yourdomain.com;

    location / {
        proxy_pass http://localhost:3000;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }
}

Walk through every feature of your app. Fill out every form. Click every button. Check every page. Compare the behavior to the platform-hosted version. Fix what's broken.

This is also when you set up your git repository if you haven't already. Every change from this point forward should be committed and tracked.

Step 7: Update DNS and go live

Once your self-hosted version works correctly, point your domain to your new server:

# Point your domain to your own server
# In your DNS provider, update:
A    yourdomain.com    → 123.45.67.89
CNAME www              → yourdomain.com

Keep the platform version running for a few days as a fallback. Once you've confirmed everything works on the new infrastructure, cancel the platform subscription.

You now own your app. No tokens. No agents. No surprise invoices.

When to hire help

You can do this migration yourself if you're comfortable with the command line and basic deployment. But there are situations where you should bring in a technical person:

  • The codebase has no tests and you can't verify it works. A developer can write basic smoke tests to make sure nothing breaks during migration.
  • You don't understand the deployment pipeline. Docker, reverse proxies, SSL certificates. If these are foreign concepts, a few hours with a DevOps engineer saves days of debugging.
  • The database schema is a mess. AI-generated schemas often have redundant tables, missing indexes, and inconsistent naming. A developer can clean this up during migration rather than carrying the debt forward.
  • You need auth, payments, or email to keep working. These integrations are critical and fragile. If the platform handled authentication and you need to set up your own, get help. Breaking auth means locking out your users.

The ideal hire is someone who understands both AI-generated code and proper infrastructure. They exist. They can read agent output, identify what's salvageable, and restructure the rest. A senior developer with AI workflow experience can migrate most apps in one to three days.

Prevention: how to avoid lock-in next time

If you're starting a new project with AI tools, you can get the speed without the trap. Here's how:

Own your git repo from day one. Every line of code should live in a repository you control. GitHub, GitLab, a self-hosted Gitea instance. Doesn't matter. What matters is that you can clone it, read it, and deploy it without any platform involved.

Use standard deployment. Docker on a VPS. That's it. No proprietary deployment pipelines, no platform-specific build steps. If your app can't run in a Docker container on a generic Linux server, you're locked in.

Insist on a real database you control. Run your own PostgreSQL or MySQL instance. Not a platform-managed database that disappears when you cancel your subscription. Your data is your business. Own it.

Keep AI as a tool, not the runtime. Use AI to write code. Use AI to debug. Use AI to generate boilerplate. But once the code is written, it should run on standard infrastructure without any AI involvement. Your production app should not depend on an AI agent to function.

Set up CI/CD early. A simple GitHub Actions workflow that builds your Docker image and deploys it on push. This takes 30 minutes to set up and removes any temptation to rely on a platform for deployment.

Document your architecture. Write down your stack choices, your patterns, your conventions. When you use AI to generate code, feed it this documentation. This is the Architecture First approach: AI produces dramatically better code when it knows your constraints.

The bottom line

AI platforms are powerful for prototyping. They compress weeks of development into hours. That value is real.

But prototyping and production are different things. A prototype needs to work. A production app needs to be maintainable, portable, and affordable. AI platforms give you the first at the cost of the second.

If you're currently paying monthly AI token fees to keep your app alive, you have options. The migration is not trivial, but it's straightforward. Export, audit, containerize, deploy, verify, switch DNS. Seven steps. On the other side is an app you own, running on infrastructure you control, with costs you can predict.

Your app shouldn't need an AI agent to keep the lights on. Ship with AI. Run without it.