IndustriesWorkPlaybookHow it worksAboutBook a systems auditBring us your idea

Playbook  /  I built it, now what: going live

How do I put my app online for the first time?

Straight answer

Put an app online in four moves: get the code into a repository, connect it to a host, add your secret settings on that host, then deploy. Test the live version hard before pointing your domain at it. Do it in that order, because an app with a database needs its secrets set to work live.

Information current as at 5 July 2026

Launching an app for the first time feels bigger than launching a plain website, and it is, but only by a couple of steps. The difference is that an app usually has a database and secrets, so there is a little more to set up before it will run in public. Here is the whole thing in order.

Plain English
Repository
The versioned home of your code, usually on a service like GitHub.
Host
The always-on service that runs your app for the public.
Environment variable
A secret setting your app needs, set on the host rather than in the code.
Staging
A private live copy where you test before real users see changes.

Step by step

  1. Get the code into a repository you ownExport or connect your project to a code repository in your own account, usually on GitHub. This gives your app a stable, versioned home that a host can deploy from, and it means you own the code rather than renting access to it inside a builder. If your tool publishes directly, you can still do this in the background so you are never locked in.
  2. Connect a host and add your secretsChoose a host suited to apps, connect it to your repository, and before deploying, add every secret your app needs (database keys, service keys) as environment variables in the host's settings. This is the step first-timers skip, and it is why a freshly deployed app so often breaks. The app cannot reach its database without these, so set them all now, not after it fails.
  3. Deploy and read the result honestlyTrigger the deploy and watch the log. If the build fails, the log names the problem, usually in the code. If it succeeds but the live app misbehaves, open the browser console on the live page and read the error, which typically points at a missing setting. Do not assume success from a green tick alone; confirm the app actually works by using it.
  4. Test every path on the live versionBefore anyone else sees it, go through the app as a user would: sign up, log in, create something, and if it takes payments, run a test payment. Do it on the live host, not the preview, because that is where the missing-settings problems surface. Fix anything that breaks now, while no real customer is watching, rather than after launch.
  5. Point your domain and do a final safety passOnce the app works on the host's temporary address, connect your domain and confirm HTTPS appears. Then do one last safety pass: are any secret keys visible in the code or the page, is the database locked down so strangers cannot read it, is there a privacy policy if you collect data. Getting an app live is easy; getting it live safely is the part worth slowing down for.
No pressure
Show us what you built.

If you have made something and it needs to become real, send it over. We will tell you honestly what it needs to be live, safe and yours, whether that is a quick fix you can do or a proper build. No obligation.

Common questions

Questions, answered

How is launching an app different from launching a website?
A plain website is fixed files a host simply serves. An app also runs code and talks to a database, so it needs its database hosted and its secret settings configured on the live host. The launch steps are similar, but an app has more to set up and a longer safety checklist before it is truly ready.
Do I need a separate database host?
If your app remembers anything, it has a database, and that database needs to be hosted and reachable by your live app. Often it lives on a service like Supabase. Make sure it is on a plan and setting that allows your live app to connect, and that it is locked down so only your app can read it.
What is the safest way to test before going public?
Deploy to the host's temporary address first and test everything there, before you attach your domain. Better still, keep a separate staging copy for future changes so you never test on the version real customers are using. Test on something private, promote to public only once it works.
When should I get help instead of pushing on?
If your app takes payments, stores personal data, or you cannot confidently answer where your data lives and whether your keys are exposed, that is a reasonable point to get a second opinion. The launch itself may be simple; the consequences of a quiet security gap are not.
Keep reading
What does deploy actually mean? →My AI built app works in preview but not live, why? →Is my AI-built app secure? →The custom platforms system →All playbook articles →
No pressure
Show us what you built.

If you have made something and it needs to become real, send it over. We will tell you honestly what it needs to be live, safe and yours, whether that is a quick fix you can do or a proper build. No obligation.

Start here

Two doors. Same senior team.

Whether you can name exactly what you want built, or you just know something is leaking, the next step is the same conversation.