4 Important Things To Consider While Taking Full-Stack App Live

Daksh kumawat Avatar

From “Works on My Machine” to a Live Full-Stack App

During my internship at Valentius Kryptix, I took a project I had built locally, a task manager with a Django REST backend and a React frontend, and deployed it so anyone can use it from a browser. Building the app was the easy part. Deploying it taught me far more.

What I Built

The project has two parts. The backend is a REST API built with Django REST Framework. It supports user registration and login with JWT authentication, and full CRUD on tasks, with every user seeing only their own data. The frontend is a React app built with Vite, using React Router for navigation. It has login, register, task list, detail, and create/edit pages, with loading and error states handled visibly.

The live app is here: https://task-frontend-one-beta.vercel.app

The Deployment Setup

I deployed the backend on Render with a managed PostgreSQL database, and the frontend on Vercel. Locally I had used SQLite, so I first had to make the backend production-ready. I moved the secret key, debug flag, allowed hosts and database URL into environment variables, added Gunicorn as the production server, and used WhiteNoise to serve static files.

Challenge 1: CORS

The first thing that broke was the connection between the two apps. The frontend loaded, but every API request failed with a network error. The browser was blocking requests from the Vercel domain because the backend did not allow that origin. The fix was to configure CORS on the backend and whitelist the exact frontend domain through an environment variable, instead of allowing every origin.

Challenge 2: Database Migrations

The backend deployed successfully, yet registering a user returned a server error. The cause was that the Postgres database was empty, because migrations had never run. Render’s free tier does not support release commands or a shell, so I added the migrate command to the build step instead. This was a good reminder that code deploying correctly does not mean the database is ready.

Challenge 3: Routing on Vercel

Navigating inside the React app worked, but refreshing a page like /tasks returned a 404. React Router handles routes in the browser, so the server has no file at that path. Adding a vercel.json rewrite that sends every route to index.html solved it.

Challenge 4: Missing Pieces

Two of my own mistakes also showed up. A page file had never been committed to Git, so the Vercel build failed with a missing import. I also realised the app had no Register page, because I had only created test users through the API. A real visitor could not have signed up. I added the page and tested the full flow on the live site.

Key Learnings

First, most deployment bugs are configuration bugs. CORS, environment variables and database setup caused almost all my problems, not the application logic.

Second, secrets never belong in Git. Every secret and URL lives in the hosting dashboards, and a local .env file stays ignored.

Third, test the deployed version the way a real user would. Registering a brand-new account on the live site found issues that local testing never showed.

Final Thoughts

Deploying this project turned it from an exercise into something real. Reading logs, reproducing errors and fixing them one at a time was the most valuable part. If you are building your first full-stack app, deploy it early and often. Debugging one broken piece at a time is much easier than debugging five at once.

Source code: github.com/dakshkumawat07/task-manager-api and github.com/dakshkumawat07/task-frontend

Tagged in :

Daksh kumawat Avatar

Leave a Reply

You May Love