I built an MVP with AI, now what? The last mile: infrastructure and deployment

Building an MVP has never been easier. With tools like Cursor, Lovable, v0, Bolt and Replit, anyone with a good idea can turn a prompt into a working product on their own screen in days, sometimes hours. And then comes the question that fills forums and communities: it is ready, it works on my machine, how do I put it online? How does a real customer access it, at a real address, without it breaking on first use? That is the last mile of the AI-built MVP: infrastructure selection and deployment. It is the stage AI tools only half-solve, and where most projects stall. This guide organizes the decisions you need to make, in the right order.

Why the last mile exists

An app running on your computer (the famous localhost) is a private prototype. To become a publicly accessible product, it needs a set of pieces the code alone does not provide:

• Hosting: a server or platform running the app 24 hours a day;
• Domain: the address (yourapp.com) people type, with an HTTPS certificate;
• Database: a persistent, secure place for the data, outside your machine;
• Environment variables: the vault for your API keys, which must never ship exposed in the code;
• Monitoring: some way of knowing the app went down before the customer complains.

The good news: for an MVP, none of this requires building servers from scratch. The right platform choice solves almost everything. The relevant decision is which path to take.

Path 1: publish through the AI tool itself

Lovable, Replit, v0 and similar tools offer one-click publishing, usually on one of their subdomains (yourapp.lovable.app) with the option of connecting your own domain. When it makes sense: to validate the idea with the first users, demo to investors and test willingness to pay. It is the fastest route in the world to a public URL. The limits: you are tied to the platform (the so-called lock-in), you have little control over performance, cost at scale and backups, and common product features (queues, scheduled jobs, complex integrations) start hitting the ceiling. Treat it as temporary parking, not as a permanent address.

Path 2: managed deployment platforms (the default for MVPs)

The middle ground that became the market standard: platforms that take your code (usually from GitHub) and handle servers, HTTPS, scaling and automatic deploys on every update. The most common names:

• Vercel and Netlify for front-ends and modern web apps (React, Next.js, what AI tools generate most);
• Cloudflare Pages and Workers for sites and applications with excellent cost and global performance;
• Railway, Render and Fly.io for back-ends, APIs and full applications;
• Supabase and Neon as managed databases (Postgres) with authentication built in.

If you want a direct starting point: for the vast majority of AI-built MVPs, our suggestion is to start with Vercel or Cloudflare Pages for the application, with Supabase for the database and authentication. It is the combination with the best balance of ease, starting cost and room to grow, and it is the one we use for our own products and sites at Espresso Labs. When it makes sense: for practically any MVP that will receive real users. The starting cost is low (many have free tiers), deployment is automated and you keep the code under your control, with no AI-tool lock-in. What to watch: prices scale with usage, so set spending alerts; and read the free tier limits before promising the app to a customer.

Path 3: traditional cloud (AWS, Google Cloud, Azure)

The path of large companies, with total control over every piece. For an MVP, it is usually overkill: the learning curve is steep, configuration mistakes are expensive (in money and in security), and the time you spend configuring a VPC is time not spent validating the product. When it makes sense: when there is a specific requirement (compliance, sensitive data, integration with corporate systems) or when the product validates and it is time to structure the definitive architecture. At that point, it pays to have a partner who does this professionally by your side: it is one of the roles Espresso Labs plays for clients who were born on paths 1 or 2 and needed to grow, designing and operating the cloud architecture so the founder does not have to become an AWS specialist.

The deployment checklist: what to verify before sharing the link

Whichever path you take, this is the minimum list before making the app public:

1. API keys out of the code. AI tools sometimes leave keys exposed in the front-end or the repository. An exposed key means a surprise bill and a data leak. Move everything to environment variables on the server.
2. Your own domain with HTTPS. Register the domain and connect it to the platform; the certificate is usually automatic.
3. Managed database with backups. No data in local files or in a database running on your machine. Confirm automatic backups are on.
4. Real authentication. Login and access control implemented with a mature service (Supabase Auth, Auth0, Clerk), not the improvised logic the prompt generated.
5. Limits and basic protection. Rate limiting on APIs and validation on the server, not just on the screen. Remember: real users do not behave the way you expect.
6. Monitoring and errors. A free uptime and error-tracking service (like Sentry) warns you about the fire before the customer does.
7. Privacy compliance from day one. If you collect personal data, have a privacy policy and a clear purpose for every piece of data, following the regulations that apply to your users (GDPR in Europe, LGPD in Brazil).

When the last mile calls for professional help

If your MVP has validated, started getting paying customers or will process sensitive data, improvisation stops paying off. It is the pattern we see most at Espresso Labs: with AI, building the product became easy, and the hard part became turning it into a good product, secure, stable and ready to grow. A good share of our clients today arrive exactly like this, with a functional AI-built MVP, hiring consulting to reinforce architecture, infrastructure, security and maintenance. In that scenario, a software house like Espresso Labs comes in as a partner for the last mile and for what comes after it: we run a diagnosis of your MVP (what to keep, what to reinforce, which infrastructure fits your scale), execute the migration and, if it makes sense, continue as the product engineering team. If you want to calibrate expectations about the real size of this stage, the project that looks 90% done is the honest companion read.

Frequently asked questions

I built an app with AI, how do I put it online?

You need hosting, a domain with HTTPS, a persistent database and protected API keys. The most common path for MVPs is connecting the code to a managed deployment platform (such as Vercel, Railway or Cloudflare) and registering your own domain.

How much does it cost to host an MVP?

For the first users, many platforms have free tiers or plans starting at a few dollars per month, plus the domain cost. What demands attention are the variable costs (AI API usage, database and traffic), which grow with the user base; set spending alerts from the start.

Can I keep my app published through the AI tool itself (Lovable, Replit)?

You can, and it is a valid way to validate the idea. To operate with real customers, migrate to a platform where you control code, domain, database and backups, avoiding total dependence on the tool.

What is the biggest security mistake in AI-built MVPs?

API keys exposed in the code or the browser, followed by validation only on the front-end. Both allow abuse of your app and generate surprise costs. Move keys to environment variables and validate everything on the server as well.

When should I hire professional help for my MVP?

When the product validates: paying customers, sensitive data or the need to scale. At that point, a professional assessment of architecture, security and infrastructure prevents rework and incidents that cost you your first customers trust.