I Built Too Many Projects. Here's What I Learned.

I have a folder full of projects that I was convinced would be the one.

Some became actual applications. Some made it to a landing page. Some have a beautifully designed README and absolutely nothing else.

For a while, I thought that was a problem.

Then I realised those unfinished projects were probably teaching me more than I gave them credit for.

I've spent the last few years jumping between Django, Next.js, APIs, databases, deployment, automation, scraping, and whatever else seemed interesting that week.

I've built things because I needed them, because I wanted to learn something, or sometimes simply because I had an idea at 2 AM and thought it was brilliant.

Eventually, I noticed something.

Starting projects was easy. Finishing them was the part that actually made me better.

I used to think every project needed to become something

When I started building projects, I treated every idea like it had to become a complete product.

I'd come up with an idea, design the interface, set up the repository, build the first few features, and get excited about what it could become.

Then another idea would show up.

And suddenly the project I was working on didn't feel interesting anymore.

So I'd start again.

There is nothing wrong with experimenting. In fact, I think experimenting is one of the best ways to learn development.

The problem is when you confuse starting with progress.

A new repository feels like progress.

A new landing page feels like progress.

A new stack feels like progress.

But sometimes the most valuable thing you can do is stay with the boring part.

Fix the bug.

Write the migration.

Handle the error.

Deploy the application.

Come back to it the next day.

Every project taught me something different

Looking back at the projects I've built, they weren't all successful.

But almost all of them taught me something.

One project might teach you how an API works.

Another teaches you that APIs can suddenly change.

Another teaches you how painful authentication can become when you don't think about it early.

Another teaches you that your beautiful local development environment means very little when production behaves differently.

I've worked across projects involving Django, Next.js, Supabase, external APIs, authentication, deployment, automation, and databases.

The interesting part is that I rarely remember the exact tutorial or documentation page that taught me those things.

I remember the problem.

I remember spending hours wondering why something wasn't working.

And I remember the moment it finally worked.

That's probably one of the biggest reasons I like building things.

Debugging teaches differently

There is a huge difference between knowing how something should work and figuring out why it doesn't.

A tutorial can show you how to create a database table.

A real project can show you what happens when your production database doesn't have the migration you thought it had.

A tutorial can show you authentication.

A real application can show you what happens when a session cookie disappears after a redirect.

A tutorial can show you file uploads.

A real CMS can force you to think about validation, storage paths, failed uploads, cleanup, permissions, and what happens when the database update fails halfway through the process.

Those problems are frustrating.

They're also useful.

I've started to think of bugs as a different kind of documentation.

They tell you what you didn't understand yet.

Finishing is a skill

This is probably the biggest lesson I've taken from all of this.

Starting a project gives you a burst of motivation.

Finishing one requires something different.

You have to deal with the parts that aren't exciting anymore.

You have to make the UI work on a smaller screen.

You have to handle an empty state.

You have to write the error handling.

You have to deploy it.

You have to discover that something you thought was finished actually isn't.

And eventually, you have to decide that it is good enough to ship.

That process is where a lot of the learning happens.

Not because the final version is necessarily impressive, but because finishing forces you to think about the entire system rather than just the interesting parts.

Deployment changes the way you build

One of the biggest differences I've noticed between building something locally and actually putting it online is how many assumptions disappear.

Locally, everything is close.

Your environment variables exist.

Your database is familiar.

Your machine is fast enough.

Your files are where you expect them to be.

Then you deploy.

Suddenly you care about:

• environment variables
• caching
• authentication
• database permissions
• storage
• domains
• DNS
• builds
• redirects
• error handling
• security
• performance

None of these things are particularly exciting when you're starting a project.

But they're part of actually building software.

That's why I now try to deploy things earlier.

It gives the project a reality check.

Not every project needs to become a startup

This one took me a while to understand.

Sometimes an idea is just an idea.

You don't need to turn every project into a SaaS.

You don't need a pricing page.

You don't need a waitlist.

You don't need to raise money.

You don't even need other people to use it.

Sometimes you build something because you wanted to understand a technology.

Sometimes you build something because it solves a tiny problem you have.

Sometimes you build something because you thought it would be fun.

That's enough.

A project doesn't have to become a business to have been worth building.

I also learned that unfinished projects aren't wasted

I still have unfinished projects.

I'm probably always going to have unfinished projects.

But I don't look at them quite the same way anymore.

Some were experiments.

Some were bad ideas.

Some were abandoned because something more interesting came along.

And some simply taught me enough that I didn't need to finish them.

The important thing is knowing the difference between abandoning something because you've learned what you wanted to learn and abandoning it because you reached the difficult part.

Those two things can look very similar.

What I'm trying to do differently now

I'm trying to build fewer things and finish more of them.

That doesn't mean I'm going to stop experimenting.

I still want to try new technologies.

I still want to build weird little tools.

I still get ideas that make me want to immediately open VS Code.

But now I'm trying to ask a few questions before starting:

Why am I building this?

What am I actually trying to learn?

What would "finished" mean?

And most importantly:

Am I willing to deal with the boring parts?

If the answer is yes, I'll build it.

If not, maybe it should stay an idea for a little longer.

What's next?

I don't think I've found the perfect way to build software.

I'm still figuring it out.

That's probably the point.

There will be more projects.

Some will be useful.

Some will be weird.

Some will probably never get finished.

But I'd rather have a collection of things I built, broke, fixed, deployed, and learned from than a collection of ideas I never touched.

So yes, I've built too many projects.

I'm probably going to build many more.

The difference now is that I'm going to try to finish a few of them.