You Built an AI App. Now Where Does It Run?

From the team behind aidrop.it — one workspace to build, host, and keep changing your code.

An AI coding agent can turn a rough idea into a working app before lunch. It can scaffold a frontend, add authentication, write an API, connect a database, and produce a README that makes the project look finished.

Then the builder asks the question that stops the momentum: where does this run?

The code sits on a laptop. The demo works on localhost. A prospective customer wants a link. The team needs a domain, a place for secrets, a database that survives a restart, and some confidence that the app will still work tomorrow.

This is the deployment gap. AI made application creation cheap and fast. It did not remove the operational decisions that turn a project into a service.

The finished demo hides the unfinished system

Local development creates a flattering environment. The API key lives in a .env file. The database runs in a container or points at a temporary account. CORS does not matter. Nobody has uploaded a large file, reset a password, or hit a rate limit.

Production changes the shape of the work. A browser needs a public URL. The app needs TLS. Secrets need a safe home. A database needs backups and a migration path — and it is where state goes, because the application itself has nowhere to write. Background work needs a worker that does not vanish when a request ends — though not necessarily a queue to feed it. Logs need to explain what happened when a user says the app failed.

Before AI coding tools, the people who could build an app often had enough engineering experience to anticipate this list. Now a designer, founder, analyst, or sales lead can produce a useful first version. That is a real gain. It also means more people reach the deployment gap without an operations playbook.

The first hosting choice should match the app, not the hype

The right place to deploy depends on what the application needs to do after a user opens it. Treating every build as a generic web app creates avoidable trouble.

A static marketing page with a form needs a reliable CDN, a custom domain, and a form endpoint — a managed frontend host covers most of that. An app with a server-side API needs a runtime, environment variables, logs, and a deployment process; a managed application platform keeps that surface small while the team learns whether users care. An app that stores customer data adds a database, access control, backups, and migrations — much like choosing build vs. buy for a memory layer, the right answer depends on the maintenance you're willing to own, not a feature checklist.

The practical question is not "what is the best host?" Ask: "which parts of this app must keep working when nobody is watching?"

A deployment checklist for an AI-built app

Before sharing a public link, run through the basics — starting with who can actually open it. You do not need enterprise infrastructure — you need enough structure to avoid losing users and data on day two.

1. A public surface. Connect a domain, turn on HTTPS, and confirm the app loads without local-only assumptions. Budget an hour for the domain itself — a root domain cannot take the CNAME every host asks for, and that is where a first launch usually stalls. The other place it stalls is earlier: an app bound to localhost is running and unreachable.
2. Secrets outside the repository. Store API keys and database credentials in the hosting environment. Rotate any key that made its way into a commit, a chat, or a screenshot.
3. Persistent data. Use a managed database or a volume with a tested backup, not a local SQLite file inside an ephemeral container.
4. A migration path. Run schema changes deliberately — a fresh database and one with real user records fail differently.
5. Logs and health checks. One place to see an error, one endpoint that says the service is alive, one alert that notices when it is not.
6. A cost boundary. Put limits around model calls, storage, and background jobs before an open endpoint turns into an unexpected bill.

AI applications add a few deployment traps

An ordinary CRUD app can fail in familiar ways. AI applications bring a separate set of failure modes.

Model calls can take longer than a browser request — if a user uploads a document and asks for extraction or a report, the work may need a queue and a worker rather than one request that waits until it times out. Prompts and model keys need the same care as any production secret: client-side code cannot keep a provider credential private, so send model calls through a server-side route. The same discipline behind securing what an agent's memory stores applies to what it sends over the wire.

Retrieval adds storage and data-quality questions, too. You need to know which documents the app indexed, when, and how a user can delete them. A vector database speeds up retrieval, but it doesn't decide retention, permissions, or provenance for you.

Deployment is becoming a product bottleneck

The old bottleneck was implementation — teams waited for someone to design the screens, write the backend, and connect the integrations. AI lowered that cost enough that deployment now appears much earlier in the product cycle.

That shift changes the first question a founder should ask after a successful demo. Do not ask whether the code looks complete. Ask whether a stranger can use it safely without your laptop, your personal API key, or your presence in the room.

Teams that handle this well keep two clear states. The experiment has the fastest path to a link and carries no sensitive data. The product has a domain, managed secrets, persistent storage, deployment records, and basic monitoring. Moving from one state to the other becomes a deliberate step, not a late-night repair after a customer arrives.

The missing layer is operational context

Deployment work contains many small decisions: the domain record, the environment variable name, the migration command, the health-check URL, the rollback condition, the owner of each credential. These details disappear quickly when they live only in a chat thread or one developer's shell history.

Keep deployment instructions, service facts, and the evidence from previous releases in a shared, versioned context layer instead. Then an AI agent can help prepare the next release from the way your team already works, instead of inventing a new path every time.

The first release is where most of that gets discovered, which is why it is worth demanding that a deploy tool tell you what is missing before it builds rather than after.

FAQ

Why does an AI-built app still need real deployment work? Because a working demo on localhost skips the parts that matter in production: a public domain with TLS, secrets kept outside the repo, a database that survives a restart, and logs that explain a failure. AI speeds up building the app, not the operational decisions around it.

What deployment traps are specific to AI applications? Long-running model calls that need a queue instead of a blocking request, provider credentials that must stay server-side, and retrieval data whose indexing, retention, and deletion rules need an explicit answer.

How do teams avoid repeating the same deployment mistakes? By keeping deployment facts — domains, secrets locations, migration steps, rollback conditions — in a shared, versioned place instead of a chat thread. aidrop.it is built for that: the same operational context follows the agent across Claude Code, Codex, and ChatGPT.