1 Project a Week: My Journey to Becoming a Better Backend Developer
Publicado em 29 de agosto de 2026
Published on August 28, 2026
1 Project a Week.
I've decided to approach my backend studies a little differently.
Instead of just taking courses, watching tutorials, and following along with other people's projects, I want to build things.
Starting now, I'm going to pick one project from my project list every week, build it from scratch, and document everything I learn along the way.
The goal is simple:
Become a better backend developer by building real projects, exploring different concepts, and understanding why things work — not just how to make them work.
Why am I doing this?
I've been studying software development for a while, and I want to focus more and more on backend development and software architecture.
But there's a huge difference between:
- knowing how to use a technology;
- knowing how to build an application;
- understanding why an architecture was chosen;
- knowing what problems that architecture solves;
- understanding its limitations and trade-offs;
- and being able to make good technical decisions.
I want to work toward the last part.
I don't want to just be able to make an API work.
I want to understand how it works and why it was built that way.
The Challenge
The idea is simple:
One project. Every week.
Each project will come from a list I've prepared specifically to push me outside my comfort zone and force me to explore different areas of backend development.
Some projects will be relatively simple.
Others will probably make me spend hours staring at my screen wondering:
"Why isn't this working?"
And honestly?
That's exactly what I want.
Because some of the most valuable learning happens when things break.
What am I going to study?
I don't want these projects to be simple programming exercises.
Each one should help me explore a different part of backend development and software engineering.
Some of the topics I expect to work with include:
- Software Architecture
- API Design
- Databases
- Data Modeling
- Authentication & Authorization
- Caching
- Message Queues
- Asynchronous Processing
- Testing
- Observability
- Performance
- Security
- Docker
- Deployment
- Scalability
- System Design
Obviously, not every project will involve all of these.
The idea is for each project to have its own challenges and learning goals.
How will I document everything?
Each project will produce three different things.
01. This blog
This is where I'll keep the most structured version of the journey.
For each project, I'll write about:
- the problem I'm trying to solve;
- the technologies I chose;
- the architecture;
- the technical decisions I made;
- the problems I encountered;
- how I solved them;
- what I learned;
- what I would do differently;
- and, whenever relevant, deeper technical details about the implementation.
I'll also share the project itself whenever possible, so the code and the documentation can be explored together.
02. A video
After finishing each project, I also want to record a video explaining what I built.
I don't want it to be just:
"Here's the project. It works."
I want to explain the entire process.
Starting with the architecture:
"Why did I build it this way?"
Moving into the implementation:
"How does this actually work?"
And finally:
"Here's the finished project running."
I also want the videos to be a way of testing my own understanding.
Because there's a big difference between writing code and being able to explain the code you wrote.
03. LinkedIn
And then there's LinkedIn.
This is where things get a little less serious. :)
I'll share the projects, what I learned, the problems I faced, and hopefully meet other developers who are also learning and building things.
And yes...
Maybe I'll do a little bit of shameless networking along the way.
Because learning is important.
But letting people know that you're learning and building can be valuable too.
The Bigger Goal
I'm not doing this series to prove that I already know everything about backend development.
Quite the opposite.
I'm doing it to discover how much I still don't know.
I want to look back at these projects months from now and clearly see the difference.
I want to:
- write better code;
- make better technical decisions;
- design better systems;
- understand trade-offs;
- solve problems more effectively;
- and become more comfortable dealing with complexity.
Most importantly, I want to develop the ability to look at a problem and think:
"I know where to start."
Project #01
Now the real journey begins.
For the first project, I'll pick the first challenge from my list and build it from the ground up.
I'll document the entire process here.
From the initial idea to the final implementation.
The documentation will roughly follow this process:
Idea ↓ Requirements ↓ Architecture ↓ Technology Choices ↓ Implementation ↓ Problems ↓ Solutions ↓ Testing ↓ Deployment ↓ Results ↓ Lessons Learned
At the end of each project, I'll also write about what I learned, what went wrong, and what I still need to improve.
One Week. One Project. One Step Forward.
I don't know exactly where this journey will take me.
Some projects might turn out great.
Some might be a complete disaster.
I'll probably rewrite code.
I'll probably make bad architectural decisions.
I'll probably discover that something I thought I understood... I actually didn't.
And that's the point.
I want to learn by building.
So this is the first entry.
Project #01 starts now.
Follow the Journey
I'll keep the projects, experiments, technical decisions, and lessons learned documented here on my website.
One project a week.
One step closer to becoming the developer I want to be.
Let's see where this goes.