Building Complex Side Projects With Purpose

Dev Leader Weekly 105

Dev Leader

Aug 09, 2025

TL; DR:

Not complexity for the sake of it
Simple projects can help you focus on the thing you want to learn.
Check out the livestream (or watch the recording) on Monday, August 11th at 7:00 PM Pacific!

Building Side Projects the Right Way

If you’ve spent any time in developer communities, Twitter, or LinkedIn, you’ve probably seen the advice:

“You need side projects to get a job.”

And if you’re early in your career, you might think: Got it. I’ll build something complex and flashy so I stand out.

Or even: Hmmm... Now I just need that perfect idea where I'll get tons of users...

But here’s the thing -- complexity isn’t the goal. The real win is in practicing the right skills and targeting the right experience gaps so that your projects actually help you land the opportunities you want.

In this newsletter, we’re going to dig into how to:

Pick the right projects for your career goals
Avoid the “next big app” trap
Use side projects to stand out on your résumé
Add complexity (on purpose!) in a way that actually builds relevant skills
Keep your project work intentional so it compounds over time

Why Side Projects Still Matter

It’s 2025. You have GitHub. You have AI tools. You have frameworks that let you scaffold a functioning app in minutes.

So why bother building side projects?

Because when you apply for jobs, especially without professional experience in that space, hiring managers look for evidence. Evidence that you can:

Take an idea from concept to a working solution
Learn new technologies
Integrate those technologies into a real product
Navigate both front-end and back-end workflows (even if you’re specializing)

If you’re early in your career, side projects show you can actually build things.
If you’re mid-career and pivoting, they show you can build things in the new domain.

Now remember, just because you have AI tools that can help you out here doesn't mean:

You should blindly vibe code until there's something that runs
OR the opposite -- completely avoid AI like the plague

It's a tool, so use it for a way that will benefit you. And what are your goals here?

Learn things (so, yeah, you need to get stuck... that's part of it!)
Demonstrate that you were learning things.

If all you do is get AI to spit out a cobbled together project that seems to work(ish), then did you accomplish your goal of learning? Probably not. And this video I put together on Claude Flow is a great example where I made something and learned NOTHING about it:

However, the goal of that project was to prove my setup worked -- not to learn about Blazor 😃

The “Next Big App” Trap

One of the most common mistakes I see is trying to come up with the “perfect” app idea that will blow people away.
Something that will surely stand out in a sea of to-do apps and calculators.

This almost always backfires. But why?

You waste time trying to invent an idea instead of building
You set unrealistic goals for scope and polish
You tie your project’s value to “wow factor” instead of skills learned

You don’t need to make the next Facebook or an AI-powered blockchain VR fitness tracker to impress people.

Instead, the magic is in taking a simple base project and deliberately adding skills you want to demonstrate. This is the whole idea behind being intentional with what you're building.

Start With the Skills, Not the App

Here’s the better starting point:

Identify where you want to be.
Is it your first dev job? A move from mobile to security? Transition from front-end to full stack?
Identify the skill gap.
Compare your current skills with what’s in job descriptions for your target role. Highlight the tools, frameworks, or domain knowledge you don’t yet have.
Pick one or two skills to focus on.
Don’t try to learn everything at once. Pick the most relevant or most common ones from your research.
Design a small project around those skills.
The “app” itself can be boring. What matters is that it forces you to learn and practice the chosen skill.

Example: Mid-Career Pivot to Security

This is actually one of the examples I talked about on Code Commute:

Let’s say you’ve been building mobile apps for 5 years but now want to work in security. Job postings mention:

Pen testing experience
Vulnerability scanning tools
Traceability frameworks

You could:

Build a basic mobile or web app
Integrate a vulnerability scanning API
Implement traceability features
Document your security considerations in the README

Now you have a project that directly addresses your skill gap without needing to invent the next billion-dollar startup. You didn't build something to be complex just for the sake of being complex... BUT you could take something simple and the complexity you introduce is simply the side effect of the other tools and technologies you are trying to learn.

How to Add “Complexity” That Counts

You’ll notice I haven’t told you to avoid complexity completely. Complexity is fine -- but only when it comes as a side effect of learning the tech or solving the problem, not as the goal itself.

Here’s how to do it:

Take a simple app idea (to-do list, blog, chat app)
Add a feature that forces you to learn something valuable for your target role
Keep the focus on implementing the new tech or skill, not expanding scope endlessly

Example:
Instead of building “just another” to-do app, build a to-do app that:

Syncs across devices in real-time using WebSockets
Stores encrypted tasks in a secure database
Has an admin dashboard with analytics

The features you choose are a direct reflection of what you’re trying to learn. The basis of the project is something simple because it gives you a platform to build on. You cut out all the noise and focus on layering in the things you are trying to learn or practice.

Side Projects Beyond Your First Job

Side projects aren’t just for juniors! They’re a tool you can use anytime you want to:

Pivot into a new domain
Learn emerging technologies before they hit your day job
Experiment without the risk of production failures

I’ve used side projects throughout my career to:

Learn unfamiliar frameworks before recommending them to a team
Explore architectural patterns I couldn’t try in an existing product
Build proof-of-concept integrations for technologies I wanted to pitch internally

It doesn't stop there though. I have BrandGhost, which is my "side project" for scheduling and cross-posting social media content. So you can use side projects to solve problems you have and potentially turn them into businesses over time.

I even started another side project to factor out the dependency injection logic from BrandGhost into a reusable set of packages called Needlr. While it's still in very early alpha, this is essentially a repackaged version of how I build the foundation for all of my plugin-based applications. For things I build beyond BrandGhost, I can re-leverage all of that work to speed up the next one.

Putting It Into Practice

If you want to start today, here’s a quick action plan:

Pick your target.
Decide the role or domain you want to grow into. Mobile? Web? Frontend or backend?
Identify one skill gap.
Find a common requirement in job postings that you don’t yet have. Notice how all of those jobs talk about Entity Framework? What about Next.js or Postgres?
Pick a simple project idea.
Use something you can build in a week or two. A simple foundation is TOTALLY fine -- so yes, a TODO app is fine.
Add a feature that closes the skill gap.
Make that feature the core focus of your learning. Go use Entity Framework as your ORM over Postgres to read and write TODO items on your dotnet backend that serves your Next.js frontend
Document and share it.
Push it to GitHub, write a short blog post, or record a walkthrough. When you try to explain things you have learned, you'll quickly find out how much you learned 😃

Build With Purpose

The point of a side project isn’t to impress people with size or flash. It’s to show intentional skill growth.

Complexity for complexity’s sake burns time and motivation. Targeted projects, built with a clear goal, compound over time into a portfolio that tells a story:

“I know where I’m going, and I’m building the skills to get there.”

That’s the kind of story that gets interviews. And if you want feedback on if it stands out on your resume, you can submit it over here.

Dev Leader Weekly