Short answer: the code was never the hard part. What the sandbox was quietly providing was hosting, a database, authentication, secret storage, a deploy pipeline and a URL, all under one subscription and one login. Export the project and you own all six, separately, with a bill and a dashboard each.
This is not a criticism of those tools. They are genuinely good at turning an idea into something clickable in an afternoon, and the bundling is exactly why. It is only worth being precise about what happens at the boundary, because the moment people hit it is the moment projects get abandoned.
What the sandbox was doing for you
- Hosting and a URL. Every save was deployed somewhere with HTTPS already configured.
- A database. Often provisioned invisibly, with the connection details managed for you.
- Authentication. Sign-in that worked without you choosing a provider.
- Secrets. A settings panel that held API keys and injected them at run time.
- A build pipeline. No configuration, no CI, no cache to invalidate.
- One bill. One subscription covering all of it.
None of those were features you chose, which is why none of them are in the export.
The five things that actually change
You own the code, including the parts nobody read. Exported projects tend to be fine structurally and weak in the places that only matter in production: error handling, loading states, input validation, and the difference between a demo that always succeeds and an app used by people with bad connections.
Secrets become your problem. Keys that lived in a settings panel now live in an env file, in a hosting console, in your CI and in your password manager. Check first whether any secret is being used from client side code, because sandboxes make that easy to do by accident and it is the most common serious bug in an exported project.
The database is yours to run. Schema, migrations, backups, row level security. If the sandbox provisioned it, find out whether you can take it over or whether you need to export the data and recreate it, and do that before you have real users rather than after.
The domain and email are new work. A custom domain means DNS. Sending email means picking a provider and verifying a sending domain with SPF, DKIM and DMARC. Neither is hard; both take a day you did not plan for.
The bill changes shape. One predictable subscription becomes four or five, most of which are subscriptions with their own floors. The total is often similar. The number of relationships is not.
When is it actually time to leave?
Not as early as people think. The sandbox is the right place to be for as long as the app is a demo, and leaving too early costs you a week of infrastructure work that buys nothing. Four signals that it is time:
- Someone is paying, or about to. Real money means real terms of service, real support and real uptime expectations, and that usually exceeds what a prototype hosting arrangement is offered for.
- You are storing data you would hate to lose or leak. Personal details, uploads, anything regulated. That needs a database you control, with backups you have tested.
- You are fighting the tool. When more of your time goes into working around the sandbox than building, the abstraction has stopped paying for itself.
- You need something it does not offer. A background job, a webhook receiver, an unusual integration, a custom domain on a plan that does not include one.
None of those is "the code would be nicer elsewhere". That one is a preference, and it is not worth a week.
The migration, in order
- Export to Git first. Get the code into a repository you control before changing anything. That is your rollback.
- Get it running locally. Install, run, open it. Fix whatever breaks. This surfaces every invisible dependency the sandbox was supplying.
- List every secret. Grep the code for keys and tokens. Move them all to environment variables and rotate any that appeared in client side code or in a shared preview link.
- Stand up the database. Create the real project, apply the schema, import the data, and turn on row level security before anyone can reach it.
- Deploy to real hosting. Connect the repository, set the environment variables, confirm a preview build works before touching the domain.
- Add email and verify the domain. Test delivery to more than one mail provider.
- Point the domain at it, then delete nothing until the new deployment has been live and correct for a week.
What to fix first in exported code
Secrets used from the browser. Anything prefixed to be public is in the bundle, and any key there should be treated as leaked. Move those calls to a server route.
Row level security that is off. A prototype database usually lets any authenticated user read everything, which is invisible until it is not.
No error handling. Every network call needs a failure path, and every form needs a disabled state while it submits.
Seed data still in the schema. Placeholder users and sample rows have a way of surviving into production.
One giant component. Worth splitting before you add features, because it is about to become the file every future change touches.
This is good work to do with a coding agent, incidentally. Point Claude Code or Cursor at the exported repository and ask for a review of exactly these five things. It is a well defined task with a clear checklist, which is where agents perform best.
What you do not need to change
Resist the urge to rewrite. The design, the component structure and the framework choice are usually fine, and a rewrite in week one is how a working prototype becomes an unfinished refactor. Change the six things above, ship it, and let real usage tell you what else needs attention.
The bill, before and after
Before: one subscription, one login, one dashboard, one renewal date. After: hosting, database, email, storage and probably a model API, each with its own account, key, console, invoice and renewal date. Often thirty to eighty dollars a month at list price for a small app, which is not the shock. The shock is going from one relationship to five in a single afternoon.
That is the gap Squiid is built for. One account provisions the services the exported app needs, holds the upstream credentials, and gives the project a single SQUIID_API_KEY so your env file stays one line long. Usage draws down prepaid credits at each provider's list price with no markup, subscription plans pass through at the provider's own price, and one invoice arrives at the end of the month. You get the ownership that leaving the sandbox gives you, without immediately acquiring five billing relationships to administer.