Hello friends!

Welcome to this week’s Sloth Bytes. I hope you had a great week.

So…

So far people are liking the 2 email format more 👀 

🦥 No sponsor this week, just vibes.

But if you want to reach 50,000+ developers, founders, and tech lovers who actually open their emails, this is the place.

Learn more about sponsoring

What Actually Makes a Good Project?

Let me tell you about a project I built.

It was 2022 (Wow I’m getting old). I spent over a month building a Facebook clone.

I called it “fakebook.”

It had everything: authentication, login with google & Facebook (funny right?), real-time messaging, feed, likes, comments, image uploads, etc.

As a college student that is technically impressive.

But it was also completely useless.

I showed it to some friends and one said "Bro, you’re not Mark Zuckerberg, I haven’t even logged in and I already broke it. Why would I use this?"

Yeah, fun times.

I learned the hard way that a "good project" depends entirely on who you're asking.

The Question Nobody Asks First:

Before you write a single line of code, you need to answer that question.

Because a "good project" for landing your first job looks completely different from a "good project" for learning a new framework, which looks different from a "good project" for solving a problem you actually have, which looks different from…

You get the point.

I personally wasted so much time building "good" projects for employers.

The problem with that is I had zero motivation or attachment to it.

• I didn’t want to finish it properly

• I didn’t want to dive deeper into topics

• I wasn’t excited to talk about it

And engineers could smell that lack of authenticity from a mile away which most likely hurt my chances in interviews.

So yeah… before we continue, let’s get this out of the way:

Let's break down what "good" actually means depending on what you're after.

Good Projects For YOU (Learning & Personal Use)

If you're building to learn or solve your own problems, a good project:

1. Solves a problem you personally have.

This is the big one. If you're building something you don't actually need, you're just doing tutorial hell with extra steps.

2. Exists at the edge of your comfort zone.

Your project should not be so easy that you're bored and not so hard that you're questioning your career choices.

Find the sweet spot. Where it’s challenging enough that you're learning and problem-solving, but not so overwhelming you abandon it by week two.

3. You can actually finish it.

If you can't ship something working in 2-4 weeks, scope it down.

Start simple. Even just the landing page.

The beauty of building for yourself is that nobody else's opinion matters. That ugly script with hardcoded values and zero error handling? Who cares.

If it works for you, it's a good project. Don't let anyone tell you otherwise.

I’ve done this multiple times on my YouTube channel:

• Typing bot

• AI Kahoot bot

I’ve made a lot of dumb things.

Good Projects For EMPLOYERS (Getting Hired)

If you're building to get hired, a good project:

1. Demonstrates specific skills they're hiring for.

Match your project to the job description keywords. If a role that mentions Next.js, Node, ad SQL, your project should showcase exactly that.

Sounds obvious, but I've seen so many people apply to React jobs with a portfolio of Python and Java projects.

2. Solves a real problem (or looks like it does).

Employers want to see that you can identify problems and build solutions.

Hiring managers/recruiters would rather see one weird, personal, fully-functional project than three textbook "portfolio projects."

3. Shows you can write production-quality code.

Good system design, some tests, error handling, logging, etc.

Bonus points if you can talk about metrics: "Reduced API response time from 800ms to 200ms" or "Implemented caching that cut database queries by 40%." Employers want to see you write maintainable code and measure its impact. That's literally the job.

Building for employers is interesting because what impresses recruiters is totally different from what impresses other developers.

Good Projects For MAKING MONEY (SaaS, Products, Business)

If you're building to make actual money, a good project:

1. Solves a painful problem people will pay to fix.

Notice I said "painful" and "will pay." Lots of problems are annoying but not painful enough for someone to pull out their credit card.

2. Targets a specific audience with money.

"Everyone" is not a target market. Get SUPER specific.

• Freelance designers who work with real estate clients

• Personal trainers

That's a target market.

And make sure they actually have money to spend because good luck getting college students to pay for something.

3. Can charge money from day one.

Here's where developers mess up, they launch free to "get users first," then monetize later.

If people aren’t using your free MVP, they definitely won't pay $50/month for the polished version.

Price validates demand.

4. Has clear paths to finding customers.

Before you write a line of code, answer this: where will your first 10 customers come from? 

If your answer is "I'll post it on Reddit and hope it goes viral," you're cooked buddy.

You need to know the exact communities, newsletters, influencers, or platforms where your target users hang out. And ideally, you're already part of those communities.

5. Can realistically compete or differentiate.

Look, I love optimism, but you're probably not going to build a better Notion or a better Slack.

You might, however, build a better X for Y niche:

• Project management for home renovation contractors

• AI assistant for mechanics.

You’re welcome for those ideas.

Building a project to make money is a completely different beast, and most developers get this wrong because they think like developers instead of thinking like business owners.

The "Indie Hacker" trap

Can we talk about the indie hacker fantasy for a second? Everyone wants to build a SaaS that makes $10k/month while they sip coffee in Bali.

Most profitable side projects make like $100-500/month and require constant maintenance.

That's still awesome if you enjoy running them, but it's not "quit your job" money.

Don’t expect too much at first.

I recommend watching Chris Raroque. He shows the whole process for building projects like this.

Good Projects For EVERYONE ELSE (Building an Audience/Reputation)

If you're building to get GitHub stars, Twitter clout, or establish yourself as a developer:

1. Have some personality.

The internet is full of boring tools. The ones that blow up usually have some charm.

Funny use case, a memorable name, a unique design, or just a developer who's fun to follow. People share things that make them smile.

2. Make it easy for others to understand and use.

Good documentation, clear setup instructions, screenshots, GIFs showing it in action. If people can't figure out what your project does in 30 seconds, they'll leave.

Your README is more important than your code for this goal.

3. Fill a gap or do something differently.

You don't need to invent something totally new, but you need an angle. "It's like X but simpler" or "It's like Y but for Z use case." There are a million Markdown editors, but some developer built one specifically optimized for writing technical documentation and developers loved it.

4. Scratch a developer itch.

If you're building for developer clout, understand that developers love tools that: automate annoying tasks, make development easier, improve workflows, make them look cool in front of their teammates, or just a cool project only a programming nerd would do.

Like this one.

I’ll be honest though, building for popularity can be exhausting and often disappointing.

Your project can get 10k stars and still make zero impact on your career if you're not strategic about it.

The Unicorn Project

Yes it IS possible to build something that genuinely serves all purposes at once:

• You learn a ton building it (personal growth)

• It solves a real problem people pay for (business)

• It looks great on your resume (employment)

• People love it and share it (audience)

This happens maybe 1 out of 50 projects, and usually by accident, not by design.

Trying to build a unicorn from day one is how you end up with an over-engineered mess that serves no goals well. Start with ONE clear goal instead.

Once you start a project, it’ll naturally evolve to serve multiple purposes.

1. You build a tool to solve your own problem (personal project).

2. You share it online (audience building)

3. A recruiter or engineer sees your tweets about it (portfolio piece).

4. You realize people are asking for a paid version with extra features (business opportunity).

When to intentionally target multiple goals:

There ARE times when targeting two goals makes sense from the start:

• Learning + Portfolio: Build something slightly beyond your skill level AND make it presentable. This is the sweet spot for students and career-switchers.

• Learning + Business: Build something you need AND validate others will pay for it. If it fails as a business, you still have a useful tool.

• Audience + Business: Build in public while building a product. Your audience becomes your first customers. This is the indie hacker playbook.

Just Start Building (Seriously)

The best project is the one you'll actually finish.

Don't plan for six months. Don't research for three weeks. Don't try to make it perfect for everyone. Just build the thing with ONE clear goal in mind.

Your future self will thank you.

They’ll actually know how to build things.

Now seriously, stop reading programming newsletters and go write some code.

Thanks to everyone who submitted!

NeoScripter, gcavelier, sayalii-e, jsjasee, AspenTheRoyal, pavithapari, grcc492, ksljivo1, and mkgp-dev!

Can You Reach the Exit?

You are given a 2D grid where each cell is one of:

• '.' - empty space (you can walk here)

• '#' - wall (you cannot walk here)

• '@' - starting position

• 'E' - exit

You can move up, down, left, right (no diagonals), and you cannot move outside the grid.

can_reach_exit([
    "@..",
    ".#E",
    "..."
])
output = True
# One path: (0,0)->(0,1)->(0,2)->(1,2) which is 'E'

can_reach_exit([
    "@#E"
])
output = False
# Exit is blocked by a wall

can_reach_exit([
    "@.#.",
    "..#E",
    "####"
])
output = False

can_reach_exit([
    "@...",
    ".###",
    "...E"
])
output = True

How To Submit Answers

Reply with

• A link to your solution (github, twitter, personal blog, portfolio, replit, etc)

• or if you’re on the web version leave a comment!

• If you want to be mentioned here, I’d prefer if you sent a GitHub link or Replit!

NEW VIDEO!

That’s all from me!

Have a great week, be safe, make good choices, and have fun coding.

If I made a mistake or you have any questions, feel free to comment below or reply to the email!

See you all next week.

Want to advertise in Sloth Bytes?

If your company is interested in reaching an audience of developers and programming enthusiasts, you may want to advertise with us here.