Today, DevCollab went fully live. The Next.js frontend is deployed on Vercel, the Django backend is on Railway, they're talking to each other over the internet, and anyone with the link can use the app. The last 99 days of building, learning, debugging, and shipping came down to this.
Deploying to Vercel
Deploying the Next.js frontend to Vercel was the simplest deployment of the entire project. Vercel was built for Next.js; it's made by the same team. The process was connecting the GitHub repository, adding one environment variable, and clicking deploy.
The build took about two minutes. Vercel ran npm run build against the repository, detected the App Router configuration, optimized all the pages, and produced a deployment. The same build that was tested locally on day 98 passed on Vercel without any changes. That's the value of running the production build locally first, no surprises.
The environment variable is the one critical piece. NEXT_PUBLIC_API_URL pointing to the Railway backend URL is the entire connection between the frontend and the backend. Getting this wrong, a missing /api suffix, a trailing slash where there shouldn't be one, http instead of https, breaks every single API call silently. Vercel's environment variable dashboard is straightforward but worth triple-checking before deploying.
The CORS Fix That Always Gets Forgotten
The first thing I did after the Vercel deployment succeeded was open the live URL and try to register. The registration failed. The browser console showed a CORS error. The Railway backend was blocking requests from the Vercel domain because it wasn't in the allowed origins list.
This is the most commonly forgotten step in any full-stack deployment. The backend was configured with CORS_ALLOWED_ORIGINS pointing at localhost:3000 for development. The live Vercel URL, https://devcollab.vercel.app or whatever Vercel assigns, was not in that list.
The fix is a one-line change to an environment variable in Railway's dashboard. Add the Vercel URL to CORS_ALLOWED_ORIGINS. Railway redeploys automatically when environment variables change. Two minutes later, registration worked.
The lesson is to always update CORS before testing the live app, not after discovering it's broken.
Testing the Live App from Scratch
With CORS fixed, I opened the live URL on my phone, a device that had never touched this app, with no local state, no cached tokens, no pre-existing data. This is the most honest test possible.
Everything worked. Registration created a real user in a real PostgreSQL database on Railway. The profile edit saved correctly. Creating a project made it appear on the browse page immediately. Searching for it by tech stack returned the right results. Opening the app in another browser, registering as a second user, and sending a collaboration request showed the pending badge on the detail page. Back on the first account, the dashboard showed the incoming request. Accepting it updated the status in place. The second account's sent requests page showed the accepted status.
The full loop, the entire reason DevCollab exists, worked on a live production URL being hit from a real device.
What Broke and What Was Fixed
Two things broke during live testing that didn't break during the Railway-connected local testing on day 98.
The first was the token refresh flow. Locally, the Next.js dev server and the Django server were both on localhost, so cookies and headers behaved consistently. On the live deployment, the Vercel frontend makes requests to a completely different domain on Railway. The Authorization header was being set correctly, but one of the Axios interceptor configurations had a withCredentials: true setting left over from an earlier attempt at cookie-based auth. On cross-domain requests, this caused the browser to add extra CORS preflight requirements that the backend wasn't configured to handle. Removing withCredentials: true fixed it.
The second was the project detail page flashing a "not found" error for about half a second before the data loaded. This happened because the page was checking if (!project) to show the not-found message, but on the first render, before the fetch completed, project was null, so it briefly showed the error. Adding a loading state check before the not-found check, only shows not-found if loading is false AND project is null, fixed the flash.
Adding the Live URL to GitHub
With everything working, the live URL was added to both GitHub repositories, in the repository description and in the README. The README got a brief section explaining what DevCollab is, the tech stack, and a link to the live app.
This is worth doing properly. A recruiter or developer who finds the GitHub repo should be able to understand what the project is and click to the live app in under 30 seconds. A repository with no description and no README is a missed opportunity.
Where Things Stand After Day 99
DevCollab is live. Two domains, one app:
Backend: Django + DRF + PostgreSQL on Railway
Frontend: Next.js on Vercel
Thanks for reading. Feel free to share your thoughts!