It works on your computer but nowhere else. Here is why.
Your app works. It looks right, the buttons do things, you have shown it to someone over your shoulder. Then you try to put it online and it either refuses, or it goes up and immediately breaks in ways it never did on your machine.
This is the point where a lot of projects quietly stop. Not because the hard part failed, but because publishing turns out to be its own separate skill that nobody mentioned.
Here is what is actually going on.
What “it works on my computer” really means
When you run your app locally, a small program on your machine is serving it to your browser, and a great deal is being handled for you invisibly:
- Your files are right there, so nothing needs uploading
- Your secret keys sit in a file on disk that your app can read
- Your database might be running locally too, or you are the only person connected to it
- There is exactly one user, you, and you never do anything unexpected
Publishing means removing every one of those conveniences at once. The app has to run somewhere it has never run, without the local files, without that key file, with a database it must reach across the internet, for people who will click things in orders you never tried.
Most publishing problems are one of those four, and they are all fixable.
The four things that usually break
Your secret keys never made it
This is the most common by a distance.
Your app needs keys — for the database, for logins, for payments. Locally these live in a file, often called .env. That file is deliberately excluded from uploads, because putting secret keys somewhere public would let anyone use them.
So the published app has no keys, cannot connect to anything, and fails.
The fix is not to upload the file. It is to add those same values in your hosting provider’s settings, usually under “Environment variables”. Same names, same values, entered once in their dashboard.
If you have ever pasted a key directly into your code because it was easier — go and find it now. Anything in your code is visible to anyone who looks. Keys get scraped from public repositories within minutes, automatically, and the bill lands on you. This is worth checking before you publish, not after.
The build step fails
Locally your app runs from your source files directly. Published, it first gets compiled into a compressed, optimised version. That compile is stricter than running locally, and things it tolerates in development become hard failures.
Unused imports, a file referenced with the wrong capitalisation, a type that does not line up. The error usually names a file and line, and it is usually a small fix once you can see it.
Capitalisation catches people out constantly: Windows and macOS do not care whether it is Header.tsx or header.tsx, but the Linux machine building your app does. It works locally and fails on deploy, with an error saying a file cannot be found that is plainly sitting right there.
Your database is not reachable
If you used a local database while building, it exists only on your machine. Nobody else can reach it, and neither can your published app.
You need a hosted database, and the app pointed at it. That also means your tables have to be created there — the structure does not travel with the app. Plenty of people ship an app that loads perfectly and then errors the instant it touches data, because the tables are empty or absent.
Everything is relative to your machine
Paths like C:\Users\you\project\images work on exactly one computer in the world. Links to localhost:3000 mean “this machine” — for a visitor, that is their machine, where nothing is running.
Search for localhost across your project before publishing. It is a two-minute check that saves an evening.
What good looks like
Once it is set up properly, publishing an update should be one action — push your changes, and a couple of minutes later the live site has them. If it is a manual ritual of dragging files, it will get skipped, and skipped updates are how sites drift into being broken.
You also want to be able to undo. Every serious host keeps previous versions and lets you roll back with one click. Knowing you can undo a bad deploy in thirty seconds changes how willing you are to ship at all.
The bit worth saying plainly
Publishing is not the glamorous part and no tutorial covers it well, but it is the difference between a thing you demo on your laptop and a thing that exists. An app only you can open is a prototype, however finished it looks.
It is also almost entirely a one-time cost. Set up correctly once, and every future update is automatic. Most people who never launch are not blocked by difficulty — they are blocked by a first attempt that failed confusingly and never got picked back up.
Want it online rather than nearly online? The free setup session covers getting a project properly configured. Bring whatever you have, including a failed deploy.