From Coding Temple to my first deployed site

A year ago I finished my bootcamp at Coding Temple and felt like I knew how to build things. I had a folder full of practice projects: a weather app, a couple of CRUD apps, a clone of something I admired. They all ran. I would type npm run dev, watch the local server spin up, open localhost:3000, and there it was. Working.

Then I tried to put one on the actual internet, and I learned that "works locally" and "live URL someone can visit" are two different skills. The second one took me three days.

Tutorials end where the hard part starts

Every course I took ended at the same place. Build the feature, run it locally, see it work, move on. That is a clean place to stop a lesson. It is a terrible place to stop if your goal is a real site.

Nobody walked me through what happens between localhost:3000 and a domain. I had a vague idea that you "deploy to Vercel" and it just goes. The reality is that your machine has been quietly papering over a dozen assumptions, and the deploy is where every one of them gets called out.

My project is not a single app. It is a monorepo: a website, a separate mobile app, and a shared package they both pull from. That structure is great for keeping code in one place. It also means the build is not as simple as "point at the repo and go."

Day one: the root directory problem

My first deploys failed before they really started. Vercel would clone the repo, look at the top level, and not find a Next.js app there, because my web app lives in apps/web, not the root.

The fix is a setting, not code. In the Vercel project settings there is a Root Directory field, and it has to point at the actual app:

Root Directory: apps/web

Once I set that, Vercel ran its install and build inside apps/web instead of the repo root. That sounds obvious written down. It was not obvious at 11pm reading a build log that just said it could not find what it was looking for. The lesson that stuck: when a deploy fails, read the log from the top, not the bottom. The first error is usually the real one. The rest is fallout.

Day two: it builds, but it's empty

With the root directory fixed, the build went green. I opened the preview URL feeling pretty good, and the page loaded with nothing working. No data. Forms that did nothing.

This was the environment variable lesson, and it is the one I would most want to hand to past me.

On my laptop I had a file called .env.local full of keys: my database URL, API keys, the usual. That file is gitignored, which is correct, you never commit secrets. But because it never goes to the repo, Vercel has no idea those values exist. My local app worked because the secrets were sitting on my hard drive. The deployed app had no secrets at all.

So I went through my local env file line by line and added each one in the Vercel dashboard under the project's Environment Variables. A few things I got wrong the first time:

• I forgot that variables exposed to the browser in Next.js need the NEXT_PUBLIC_ prefix. Server-only secrets do not get that prefix, and they should not, because anything NEXT_PUBLIC_ ships to the client.
• Adding a variable does not change a build that already ran. You have to redeploy for new env vars to take effect. I sat there refreshing a page that was never going to change until I triggered a fresh build.
• A trailing space pasted into a key is invisible and will break it. I had one. It cost me an hour.

I keep an .env.local.example file in the repo now, with the variable names and no values, so future me has a checklist of what production needs.

Day three: the small settings

The last day was the boring stuff that is only boring once you understand it. Build command, install command, output settings. With a monorepo and a shared package, the install step has to pull dependencies for the whole workspace, not just the one app, or the build cannot find the shared code it imports.

I will not pretend I had a deep theory here. I read Vercel's docs on monorepos, matched my settings to how my workspace is actually structured, redeployed, and read the log each time. That loop, change one thing, redeploy, read the log, is most of what deploying actually is. It is not glamorous. It is patient.

Then a build went green, I opened the production URL, and the site was there. Real domain. Data loading. Forms submitting. Three days for something the tutorial made look like one button.

What I actually learned

The gap between learning and shipping is not about writing better code. My code was the same on day zero and day three. What changed was that I learned the layer underneath: where secrets live, why a build does not know what your laptop knows, how a project's structure has to be spelled out to a machine that has never seen it.

If you are coming out of a bootcamp with a folder of projects that all "work," the most useful thing you can do is deploy one of them. You will hit these walls. Hitting them is the lesson. A practice project on your laptop teaches you to build. A live URL teaches you everything the build was hiding.

I am still early in all of this, and I am sure I will find more walls. But the site is up now, and I learned more in those three frustrating days than in a month of things that ran cleanly the first time.

If you want to see the actual receipts, what I have shipped and what I am still figuring out, I keep them honest on my proof page: aldowebsitellc.xyz/proof.