Brief:
There’s nothing quite like pushing your first real app to production. It’s exciting, nerve-racking, and brutally honest. In this post, I walk through the first time I deployed a web app, the problems I ran into, how I fixed them, and the hard lessons that stuck with me after the dust settled.

The Moment Everything Got Real

You can write code all day, test it locally, and feel like a pro — but the moment you deploy, it gets real. That’s the day your app leaves your machine and faces the world.

I remember the excitement of building my first full-stack app. I had everything working locally — React on the front end, Node and Express on the back end, MongoDB handling the data. I was proud of it. I was ready to ship.

Or so I thought.

Mistakes I Didn’t See Coming

1. Environment Variable Chaos

Everything worked perfectly on my machine, but as soon as I deployed, nothing connected. Turns out, I hadn’t properly set up my environment variables on the hosting platform. No database URI, no JWT secret, no port config. Just errors.

Fix: I created a .env file with dummy values and mirrored the exact variables in my deployment settings (on platforms like Render, Railway, or Heroku). I also made sure to never push that .env file to GitHub.

2. CORS Drama

My frontend refused to talk to my backend in production. Locally, it was fine. In production? Total silence. The browser threw CORS errors I hadn't seen before.

Fix: I added proper CORS middleware to my Express server and whitelisted my deployed frontend URL.

3. Broken Build Paths

React routes that worked locally gave 404s in production. Refreshing a dynamic route crashed the page.

Fix: I configured my server to serve the index.html file for all unknown routes, allowing React Router to handle client-side routing.

4. Logging Everything (Including Sensitive Data)

During debugging, I had a bunch of console.log() statements printing sensitive things like tokens, passwords, and user info.

Fix: I scrubbed my code clean before the next push. Lesson learned — logs are helpful, but be careful what you expose.

What I Learned From That Day

1. Testing Locally Isn’t Enough

Local development is safe. Deployment is not. I started thinking in terms of environments — dev, staging, and production — and testing across them.

2. Document Everything

I started writing down every step I took during deployment. That doc helped me the next time I deployed and saved me from repeating the same mistakes.

3. Stay Calm When It Breaks

Things will go wrong. It’s part of the process. What matters is how quickly and calmly you debug, trace the issue, and apply the fix.

Conclusion

The day I went live was humbling, but also empowering. I messed up, patched it up, and walked away sharper. Since then, every new deployment has gotten a little smoother.

You don’t truly understand what you’ve built until you deploy it. That’s where the real lessons kick in.

The Day My Code Went Live