Deploying Your First App for Free

When you build an app on your computer, it runs on localhost. That is your machine acting as a temporary server. Nobody else can see it. If you close your laptop, the app disappears.

Deployment is the process of putting your code on someone else's computer (a server) that stays on 24/7 and is connected to the internet. When you deploy, your app gets a URL that anyone in the world can visit. That is it. There is no magic. You are just copying your code to a computer that is always online.

Years ago, deployment was genuinely hard. You had to rent a server, install an operating system, configure a web server like Nginx or Apache, set up SSL certificates, and manage security updates. Beginners had no business touching any of that. Today, platforms like Vercel and Netlify have reduced the entire process to "connect your GitHub repo and click a button." The hard parts are automated.

This matters for your career too. Employers want to see live projects, not screenshots. A portfolio site with links to working apps shows that you can build something real. And the deploy process itself teaches you things (environment variables, build errors, production vs development) that you cannot learn from localhost alone.

There are dozens of hosting platforms, but four stand out for beginners because they are genuinely free (not "free trial"), easy to use, and have generous limits.

Vercel is the best starting point for frontend apps. It was built by the team behind Next.js, but it works with plain HTML, React, Vue, Svelte, or any static site. The free tier is generous: unlimited deploys, automatic HTTPS, preview URLs for every git push, and custom domain support. If you are building anything with React, Vercel is the obvious choice.

Netlify does almost exactly what Vercel does. The interface is slightly different, but the core experience is the same: connect your repo, configure the build command, and deploy. Netlify also has "Netlify Functions" for small backend tasks, which can save you from needing a separate server for simple things like form submissions or API calls.

Railway handles full-stack apps. If your project has a backend (Node.js, Python, Go) or needs a database (PostgreSQL, Redis, MongoDB), Railway is where you go. The free tier gives you a limited number of execution hours per month, which is plenty for portfolio projects and learning. Railway also provisions databases with a single click, which is much easier than setting them up manually.

Render is similar to Railway but with a different pricing model. You get free static site hosting (like Vercel/Netlify) plus free web services with some cold-start delays on the free tier. That means your app might take 30 to 60 seconds to "wake up" if nobody has visited it recently. For portfolio projects, that is fine. For production apps, you would upgrade to a paid plan.

A good rule of thumb: if your project is frontend-only (HTML/CSS/JS, React, etc.), use Vercel or Netlify. If your project has a backend, use Railway or Render.

Let us walk through deploying a project to Vercel. This assumes you have a project on GitHub already. If your code is only on your computer, push it to a GitHub repository first.

Step 1: Create a Vercel account. Go to vercel.com and sign up with your GitHub account. This is the easiest path because it connects your repos automatically.

Step 2: Import your project. After signing in, click "Add New" and then "Project." Vercel will show you a list of your GitHub repositories. Find the one you want to deploy and click "Import."

Step 3: Configure build settings. Vercel auto-detects most frameworks. If you are using React (Create React App or Vite), it will set the build command and output directory for you. For a Vite project, the defaults are usually:

• Build Command: npm run build
• Output Directory: dist

If you are deploying a plain HTML/CSS/JS site with no build step, you can leave these blank.

Step 4: Add environment variables (if needed). If your app uses API keys or other secrets (like a Supabase URL), add them here. Never put API keys directly in your code. Vercel stores them securely and injects them during the build process.

Step 5: Click "Deploy." That is it. Vercel will clone your repo, run your build command, and give you a live URL in about 30 to 90 seconds. The URL will look something like your-project-name.vercel.app.

What happens next: Every time you push new code to your GitHub repo, Vercel automatically rebuilds and redeploys your app. You never have to manually deploy again. Push to main, and within a minute or two, your live site is updated. Vercel also creates "preview deployments" for pull requests, so you can test changes before merging them.

Your first deployment will probably fail. That is completely normal. Here are the errors that trip up almost every beginner.

"Build failed" with missing dependencies. This usually means you installed a package locally but forgot to save it to package.json. Run npm install package-name (not npm install package-name --no-save) and push the updated package.json and package-lock.json to GitHub.

Environment variables not working. If your app works locally but breaks in production, you probably forgot to add your environment variables in the deployment platform's dashboard. In Vercel, go to your project settings, then "Environment Variables," and add each variable your app needs. Remember that Vite apps need variables prefixed with VITE_ to be accessible in the browser.

Case sensitivity issues. Your computer (especially macOS and Windows) might not care about uppercase vs lowercase in file names. Servers do. If you import from './Components/Header' but the file is actually named header.tsx, it works on your machine and fails in deployment. Check your imports carefully.

"Module not found" errors. Similar to missing dependencies, but sometimes caused by typos in import paths. The deployment logs tell you exactly which file and which import is failing. Read the error message. It is almost always pointing directly at the problem.

Build works locally but fails on Vercel. Run npm run build on your own machine first. If it succeeds locally, compare your local Node version with what Vercel is using. You can specify the Node version in Vercel's settings or add an "engines" field in your package.json.

The single best debugging strategy for deployment errors: read the build log from top to bottom. The platforms provide detailed logs showing exactly what happened. The actual error is usually near the end, and it almost always tells you what went wrong in plain language.

Your deployed app gets a free URL like your-project.vercel.app or your-project.netlify.app. That works, but if you want something more professional like yourname.com or myportfolio.dev, you need a custom domain.

Where to buy a domain. Namecheap and Google Domains (now Squarespace Domains) are the most popular registrars. A .com domain costs around $10 to $15 per year. .dev domains are a bit more. Avoid buying from your hosting provider if possible, because it makes it harder to switch hosts later.

How to connect it to Vercel. In your Vercel project settings, go to "Domains" and add your domain name. Vercel will give you DNS records (usually a CNAME or A record) that you need to add in your domain registrar's dashboard. The exact steps depend on your registrar, but Vercel's documentation walks through each one with screenshots.

SSL/HTTPS is automatic. Both Vercel and Netlify automatically provision SSL certificates for custom domains. You do not need to set up HTTPS manually. Once the DNS propagates (usually within a few minutes to a few hours), your site is accessible via https://yourdomain.com with the padlock icon and everything.

A professional domain is not strictly necessary for learning, but it makes a real difference when you are sharing your portfolio with potential employers. kiptoo.dev looks better on a CV than random-string-123.vercel.app.

Most beginners wait until their project is "finished" before deploying. This is a mistake for several reasons.

First, deployment reveals problems that localhost hides. Environment variables, case sensitivity, build configuration, API endpoints that work locally but not in production. Finding these issues after you have written thousands of lines of code means debugging in a codebase you barely remember. Finding them on day two means fixing a small, isolated problem.

Second, having a live URL changes your motivation. There is something psychologically different about "my app is on the internet" versus "my app runs on my laptop." You can share the link with friends, get feedback, and feel like you are building something real. That matters when you are learning and need every bit of motivation you can get.

Third, it teaches you the deployment workflow early. Continuous deployment (pushing code and having it automatically go live) is how professional teams work. If you start doing this from your first project, it becomes second nature. By the time you are working on a team, you will not be the person who is afraid to deploy.

The practical advice: deploy your project as soon as it does one thing. Even if it is just a heading that says "Hello World." Get the deployment pipeline working first. Then build features, push them, and watch them go live. It is a much better feedback loop than building locally for weeks and then fighting deployment errors at the end.

Once your first app is live, you have crossed a real threshold. You are no longer someone who is "learning to code." You are someone with a live project on the internet. That is a meaningful distinction.

From here, a few things are worth learning:

• Environment variables for managing API keys and secrets across local and production environments
• Databases so your app can store data permanently (see our databases for beginners guide)
• CI/CD pipelines for running tests automatically before each deployment
• Monitoring and error tracking so you know when something breaks in production

But do not rush into all of that. Enjoy the moment. You built something and shipped it. Most people who say they want to learn to code never get this far.

If you want a structured path that takes you from first deploy to building production-quality full-stack applications, check out McTaba's Deployment: Going Live course (KES 4,999). It covers domains, DNS, CI/CD, environment management, and the real-world deployment patterns that professional teams use. Or if you want to start from the foundations, create a free McTaba Academy account and explore the curriculum.