DEV Community

Cover image for Why I Started Building One Backend Project Every Day (And You Should Too)
Omkar Gawde
Omkar Gawde Subscriber

Posted on

Why I Started Building One Backend Project Every Day (And You Should Too)

Three months ago, I was that developer who could build a decent React frontend but turned into a deer in headlights the moment someone mentioned "database schema" or "API endpoints." You know the type - great at making things look pretty, terrible at making them actually work.

Then I got tired of being the "frontend person" in every conversation and decided to do something completely unreasonable: build a new backend project every single day for a month.

Spoiler alert: It was one of the best terrible ideas I've ever had.

The Problem With "Learning Backend"

Here's the thing about backend development - it's intimidating as hell when you're coming from frontend land. Frontend feels immediate and visual. You change a color, boom, you see it. You add a button, click it, it does something.

Backend? You're dealing with invisible stuff happening on some server somewhere, databases that might explode if you look at them wrong, and error messages that read like they were written by someone who hates you personally.

Most tutorials don't help either. They're either:

  • Too simple ("Here's how to make a hello world API!")
  • Too complex ("Let's build Twitter but with microservices and Kubernetes!")
  • Too boring ("Today we'll learn about database normalization...")

I needed something that would force me to actually understand this stuff without making me fall asleep.

The Daily Project Rules (AKA How to Not Burn Out)

I set some rules to keep myself sane:

Rule 1: Keep it stupidly simple
No fancy architectures, no trying to build the next Facebook. Just basic CRUD operations that actually work.

Rule 2: Different tech each time
One day Express.js, next day FastAPI, then maybe some Go. The goal was breadth, not depth.

Rule 3: It has to DO something
No more tutorial hell. Each project had to solve a real (even if tiny) problem I actually had.

Rule 4: Document the pain points
Every time I got stuck, I wrote down what confused me. This became gold later.

Week 1: Everything Is On Fire 🔥

My first project was a simple expense tracker API. Should be easy, right? Track expenses, get expenses, done.

Four hours later, I'm googling "why does my database keep saying connection refused" at 2 AM like some kind of backend goblin.

Turns out I had:

  • Wrong database connection string
  • Forgot to actually start the database
  • Mixed up async/await syntax
  • No idea how middleware works
  • A profound confusion about what a port number is

But you know what? By day 3, I wasn't googling basic connection issues anymore. By day 7, I could set up a basic REST API without wanting to throw my laptop out the window.

Week 2: Things Click (Sort Of)

Started building random stuff:

  • A URL shortener (learned about redirects)
  • A simple chat API (discovered WebSockets exist)
  • A weather app backend (API keys are a thing)
  • A note-taking API (CRUD operations finally made sense)

Most of these projects were terrible. Like, really bad. But they WORKED, which was a huge mental shift from "I have no idea what I'm doing" to "I can figure this out."

Week 3: The Breakthrough

This is when it got interesting. I started recognizing patterns:

  • Most APIs follow similar structures
  • Error handling is basically the same everywhere
  • Databases aren't trying to personally attack me
  • Authentication is confusing but not impossible

I built:

  • A habit tracker backend (finally understood user sessions)
  • A file upload service (learned about middleware properly)
  • A simple job queue (discovered background processing)
  • A basic analytics API (aggregation queries clicked)

Each project built on lessons from the previous ones. It felt like those moments in video games when you finally understand the mechanics and everything becomes fluid.

What Actually Changed

The Technical Stuff:

  • Went from "what's an endpoint" to building functional APIs
  • Actually understand databases now (shocking, I know)
  • Can read documentation without crying
  • Know enough to be dangerous with Docker and deployment

The Mental Shift:

  • Backend stopped feeling like black magic
  • Started thinking in systems instead of just components
  • Gained confidence to take on full-stack projects
  • Realized most "complex" backend stuff is just simple stuff connected together

Should You Actually Do This?

Look, building a project every day is kind of insane. But here's what I'd recommend:

Start with 3 projects a week - gives you time to actually understand what you're building

Focus on solving real problems - even tiny ones from your own life

Use different tools - don't get stuck in one ecosystem

Document everything - future you will thank present you

Deploy your stuff - it's not real until it's running somewhere

The Bottom Line

Most people overthink learning backend development. They want to understand everything before they start building anything.

But here's the secret: you learn by building, not by reading. And you build confidence by shipping things, even if they're small and terrible.

Three months later, I'm not a backend expert. But I'm also not intimidated by backend work anymore. I can spin up an API, connect it to a database, and deploy it without having an existential crisis.

Sometimes the best way to learn something is to just start doing it badly and improve as you go.


What's stopping you from building that project you've been thinking about? And what's the smallest version you could actually finish this week?

Top comments (0)