What Is Deployment? How Your Code Becomes a Live SaaS

What is deployment? It is moving your product from your own computer, where only you can see it, to a cloud server where anyone with the URL can use it. While you build, your app lives at a local address only your machine can reach. Deployment packages it up, uploads it to a hosting provider, and gives it a public address. With modern tooling, that entire journey — from saving your code to a live, updated website — takes about 2 minutes.

If you're a non-technical founder building with AI, deployment is the moment your project stops being a file on a laptop and starts being a business. Here's the whole picture, jargon translated.

Local vs production: cooking at home vs running a restaurant

Every app lives in two worlds. Local development is your computer: only you can see the app, changes appear instantly, and error messages show you everything, because the only person who'll ever read them is you. It's where you build, test, and experiment freely.

Production is the live version real users touch. The code is optimised for speed, error messages are deliberately vague (detailed errors leak information attackers can use), and the app runs on infrastructure that scales automatically when traffic grows.

The analogy that makes it stick: local is cooking at home — only you and your family eat it. Production is a restaurant — the public can order. Deployment is opening the doors.

What is deployment? What actually happens when you deploy

Deployment has two steps hiding inside it. First comes the build. Your development code is spread across many readable files, written for humans. The build step bundles those into a few compact files, strips out everything unused, and shrinks what's left so pages load fast. Think of it as vacuum-packing your app for shipping — same product, a fraction of the size.

Second comes the upload. The built files go to a hosting provider's servers. You could do this manually, but nobody does anymore. The modern way is git integration: you connect your code repository to the host once, and from then on every time you push code, the host automatically pulls the latest version, builds it, and updates the live site. Code saved → live website, in about 2 minutes, with no manual steps. That automation is called continuous deployment, and it's the reason solo founders can ship daily. (Why you should ship that often is its own story.)

Where your SaaS actually lives: hosting

Hosting is renting server space so your product runs on someone else's infrastructure — along with the unglamorous essentials: security certificates for the padlock in the browser bar, a global delivery network so your app is fast everywhere, and protection against attacks. The three big names for solo founders:

All three are excellent; I recommend Cloudflare Pages for its unlimited free bandwidth. But hosting only covers your frontend — the part users see. Your backend — database, user accounts, file storage — lives separately, typically on Supabase. Its free tier (a 500MB database, 1GB of file storage, 50,000 monthly active users) covers an MVP comfortably; the $25/month Pro tier adds daily backups and more room when you grow. Two services, and your entire product is live. It's a big part of why the full cost of building a SaaS collapsed.

The bookThe Solopreneur RevolutionLuis Gonçalves on building a solopreneur business with AI while employed.Get the book →

One codebase, different settings: environment variables

Your local app should talk to a test database; your live app must talk to the real one. But it's the same code. The answer is environment variables — settings that live outside your code and change per environment. Locally, they point at test services with test keys. In production, the hosting provider injects the real values during the build.

This matters for security as much as convenience: secret keys never get written into your code, so they never end up publicly visible in your repository. Same code, different values, secrets kept out of sight.

Preview deployments: test the change before it's live

Here's a feature that feels like magic the first time. When you prepare a change on a separate branch of your code, the host automatically deploys that version to its own private URL. You can click through the new feature in a production-like environment, share the link for feedback, and only merge it into the live site when it's right. If it's wrong, you discard it — production never knew.

When a deploy goes wrong: the 30-second rollback

You will eventually ship a bug. The old instinct — find it, fix it under pressure, redeploy, pray — is the wrong move. Every deployment you've ever made is kept, and the platform lets you roll back: click the last working version, confirm, and the live site reverts. Time to recover: about 30 seconds. Then you fix the bug calmly, test it, and redeploy when ready.

That safety net changes your psychology more than your process. Deployment stops being a high-stakes event and becomes routine — which is exactly how you should treat it.

12 weeksYour corporate career was never the planApply to the Solopreneur Accelerator.Apply now →

Frequently asked questions

What does it mean to deploy an app?

Deploying means taking the app that runs only on your computer, packaging it into an optimised bundle, and uploading it to a hosting provider so it's live on the internet with a public URL. Modern platforms automate the whole thing: push your code and the live site updates itself in about 2 minutes.

What's the difference between local and production?

Local is your private workshop — only you can see the app, and it's set up for fast experimentation with detailed errors. Production is the public version — optimised for speed, connected to the real database, with vague error messages for security. Same product, two environments, different settings via environment variables.

How long does a deployment take?

The first setup — connecting your repository, adding environment variables, pointing your domain — takes an afternoon, and a build runs 2–5 minutes. After that, every deployment is automatic: push code, wait roughly 2 minutes, and the live site is updated. Custom domains need a one-time DNS change that can take up to 24 hours to propagate.

What happens if I deploy a bug?

You roll back. Hosting platforms keep every previous deployment, so reverting to the last working version takes about 30 seconds from the dashboard. Fix the bug locally without pressure, then redeploy. Preview deployments catch most bugs before they ever reach production in the first place.