DEV Community

Cover image for Stop building side projects. Nobody cares — and here's the uncomfortable math.
Info Inlet
Info Inlet

Posted on

Stop building side projects. Nobody cares — and here's the uncomfortable math.

Readers debate coding for passion versus profit

Open your GitHub. Go on. Count the repositories that have a README, a clean commit that says initial commit, maybe a second one that says wip, and then… nothing. No third commit. No user who isn't you. No issue filed by a human you've never met.

I'll wait.

I count nine on mine. Nine little tombstones. A URL shortener. A habit tracker. Two different note-taking apps because I didn't like how the first one turned out. A "Twitter but for X" from a week I should have been sleeping. Each one started on a Saturday with the specific electric feeling that this was the one, and each one died on a Wednesday when the part that was actually hard showed up.

I built the graveyard. Most of us did. And I want to say the thing nobody says at the start of the "build in public, ship every weekend, your portfolio is your résumé" sermon:

Nobody cares about your side project. Not one person. And the math on why is worse than you think.

Stay with me, because this isn't a doomer post. There's exactly one kind of side project that's still worth every hour — and the math is what tells you which one.

The three lies we tell ourselves before the first commit

You don't build a side project for no reason. You build it because you believe one of three things:

  1. It'll teach me. ("I'll finally learn Rust / Kubernetes / that framework.")
  2. It'll get me hired. ("Recruiters will see this and know I'm serious.")
  3. It'll make me money. ("Maybe this one's a business.")

All three are real motivations. All three are, as usually practised, mathematically doomed. Let me take them one at a time, because the doom is instructive — it points straight at the one version that survives.

Lie #2 first, because it's the load-bearing one: nobody is reading your code

Let's do the one everybody believes hardest.

A recruiter has never, in the history of hiring, cloned your repo. They have not read your code. They did not git log your commit hygiene at midnight and think ah, a craftsman. The eye-tracking studies on résumés put the average first pass at somewhere around six or seven seconds — and your GitHub link, if it's clicked at all, gets the profile page, the green squares, and a scroll. That's it.

Here's the part that actually stings, and it's new. The day an AI could scaffold a polished, deployed, nice-looking side project in an afternoon, the signal value of "I built a side project" fell to zero. Not low. Zero. Because the thing the portfolio was supposed to prove — "this person can take an idea to a running app" — is now something a motivated teenager does over lunch with a chat window. You cannot signal scarcity with a thing that just became free.

So the résumé math is: N polished repos × (signal that anyone can now generate for free) = 0. Adding more repos multiplies zero. It's still zero. You cannot out-volume a value that collapsed.

Lie #3: the user math is even more brutal

"But maybe it's a business."

Okay. Count your users. Not signups — the number who came back on day seven and did the thing again. For nine out of ten side projects that number is, precisely, one. You.

10 side projects × 0 real users each = 0. And here's the trap the AI era set: it made the building free and did nothing about the zero. The hard part of a product was never the code. It was getting one stranger to care, come back, and hurt you when it broke. AI compressed the easy 20% — the typing — to nothing, and left the impossible 80% — distribution, retention, trust — exactly as impossible as it always was. So the modern graveyard fills faster than ever, because building the tombstone got cheap and burying it still costs the one thing nobody can generate: another human's attention.

Lie #1 is the only one with a survivor in it

"Fine — but at least I learned something."

Did you? Be honest about what.

If you followed the shape of a tutorial, wired up the same auth-and-CRUD you've wired up before, deployed it, screenshotted it, and moved on — you produced output. A thing that exists. And output, again, is now free. You learned the syntax, the flag order, the incantation. That's recall, and recall is the part AI ate first and you're better off without.

There's a completely different thing hiding inside "I learned something," and it only shows up under one specific condition:

A side project produces output. Only a side project with a real user who can hurt you produces judgment. Output is now free. Judgment is the entire game.

You do not earn judgment by building. You earn it by shipping to someone who can churn, complain, refund, and file a furious bug at 2am — and then living through the consequence. That's the forge. Everything before it is a tutorial with your name on the commit.

The one project that was worth all nine tombstones

I have one repo that isn't in the graveyard. One thing I shipped that a real, paying stranger actually used.

And it taught me something no tutorial could, because it cost me a real person's bad night. I had a write path that acknowledged the request before it had actually persisted the row. In the demo, in the tests, on my machine — flawless. Then one day a retry hit at the wrong moment, the ack went out, the save didn't land, and a paying customer got locked out of their own account with no record that they'd ever done the thing. Ack-before-persist. I can still feel it.

No course gave me that. No amount of scaffolding a tenth side project would have. I earned it the slow, expensive, humiliating way — because there was a real human on the other end of the glass who could be hurt by my mistake, and was. That single scar is worth more than the other nine repos combined, and it's the only line on my GitHub that would have been worth an entire interview.

That's the math nobody puts on the "ship every weekend" poster: nine projects with zero users taught me nine times nothing. One project with one real user taught me the thing I now build my whole career around.

Be clear about what I'm actually saying — because it's not "don't build"

I am not the guy telling you to stop making things. I make things constantly. I let AI generate output all day long — it writes most of my code, and I'd never go back. Building is joyful and you should do it for the joy alone, no defense required.

What I'm saying is narrower and, I think, freeing:

Stop building side projects as a strategy. They were never the scarce thing, and the day AI made them free, "I built ten of these" stopped meaning anything to anyone but you. The strategy that's left is the boring, terrifying one nobody screenshots:

  • Build one thing.
  • Put it in front of one real stranger who can hurt you — someone who will churn, complain, or ask for their money back.
  • Keep it alive. Maintain it through the 2am. Feel the ack-before-persist for yourself.

One shipped-and-maintained thing that a real person depends on will teach you — and, incidentally, show an interviewer — more than a hundred green-squared weekends. Not because it's more impressive. Because it's the only place judgment is actually minted.

Why this is the exact reason I build the way I do

Here's the part that goes one level up, because it's the same math.

I build an agent platform, and the temptation in this whole industry right now is to celebrate the author — the thing that generates. Look how fast it ships! Ten side projects an afternoon! But an author that produces infinite output is producing infinite unblessed diffs. A GitHub graveyard is exactly that: a pile of things generated and never judged, never shipped into contact with a reality that could hurt you. The volume was never the point. The volume is now free.

So I never let the thing that writes the code be the thing that blesses it. There's an author that produces the diff, a separate skeptic whose only job is to try to break it rather than admire it, and a human on the merge button who can see the blast radius the model can't. That separation — author, skeptic, human — is the whole shape of xenition, and it's the same lesson the graveyard teaches: generating a thing is free and always will be; deciding whether it survives contact with a real user is the entire job. Output is cheap. Judgment is the product.

Your GitHub graveyard isn't a sign you're lazy. It's a sign you were optimizing for the free thing. Stop. Build one thing that can hurt you, and stay.


Honest question for the comments: how many tombstones are on your GitHub right now — and which one project, the one you actually shipped to a stranger, taught you something none of the others did? I want to hear about the one that survived. 👇

(If this made you close a few dead tabs with a little less guilt, a ❤️ and a 🔖 help it reach the next person staring at their graveyard on a Saturday.)

Top comments (25)

Collapse
 
hbtester1973 profile image
HBTester • • Edited

Reading this made me realise there are fundamentally two types of people who learnt to code.

  1. The ones that like coding.
  2. The ones that are in it for the business.

Glad I know which side I'm on now.

Side note: really sad there is not a 💩 to react with for AI slop like this.

Collapse
 
infoinlet1 profile image
Info Inlet •

Fair — and honestly the two-types split is a good frame. I'd just push back on it being clean: the ones who only like coding tend to build the graveyard, and the ones who only want the business tend to ship things nobody wanted. The whole post is arguing for the third type — the one who likes building but ships it to someone who can hurt them. That's not a side you're born on, it's one you choose per project.

On the 💩: totally fair to want it, and I'd genuinely defend your right to fling it. But notice what happened — you read a ~2000-word argument, disagreed with none of the actual claims, and reached for the label instead of the counterpoint. "AI slop" is doing the same job the green squares were: a cheap signal that saves you from the expensive thing, which is saying which part is wrong.

So I'll take the bait honestly — which line doesn't hold up? If it's slop, it should be easy. I'd rather get that comment than the 💩.

Collapse
 
hbtester1973 profile image
HBTester • • Edited

I called it AI slop because the language reads like AI written, which 90% of all posts on this site are anyways. Oh well.

Regarding the actual content, I don't agree with the entire premise of your argument.

Now I was going to argue the whys, then I saw your profile and realised you're an AI company pushing AI tooling. Ofcourse you're gonna say making sideprojects without users is worthless. I'm not gonna waste my time anymore.

Please don't waste more tokens to craft a response to this and ruin the planet more.

Thread Thread
 
infoinlet1 profile image
Info Inlet •

Fair enough — and I'll keep this short to honor the planet.

The bias point is legit to raise. I do build AI tooling, and you're right to weigh that. But "he's biased" and "he's wrong" are different findings, and only the first one is on my profile. The argument doesn't need you to trust me — it stands on whether a repo with zero users taught you less than one with a real user, which is checkable against your own graveyard, no AI company required.

You said you don't buy the premise. That's a completely fine place to land. I just can't tell which part you reject, so I can't learn anything from it — and that was the only reason I asked. No hard feelings either way. Genuinely, thanks for reading two thousand words you didn't like. That's more than most. 🤝

Thread Thread
 
kg7hf profile image
P.R.Decker •

I have 2 followers on my github, and I only know one.
I've got hundreds of projects, most of them private, most of them for me only. A few I've spent a day or two on, learned what I needed, others have lasted multiple years, others I haven't solved and pick at them little by little. One in particular I showed a perspective employer and it was instrumental in my landing the role.
The theme should be to do what you want, take what you want to take from it. If you have an idea, go, if you get bored or lose interest, fine, that's okay too!

my-github

Collapse
 
mrtigafk profile image
Kaushik N •

Lol loved the poop comment

Collapse
 
sinarezaei profile image
Sina Rezaei •

This one hits a point I’ve been thinking about too. The output vs. judgment distinction is probably the most important part for me. Building another project and getting it to work is one thing. Finding out what happens when an actual person starts relying on it is a completely different experience.

AI makes the first part much easier now. You can go from an idea to a working demo ridiculously fast. But that doesn't mean the hard problems disappeared. They just moved further down the road: edge cases, bad assumptions, maintenance, user behavior, and all the stuff you don't think about when you're building alone.

So I don't think the problem is having side projects. It's when the number of projects becomes the goal instead of what you actually learned from putting something into the real world. That distinction makes a lot of sense to me.

Collapse
 
infoinlet1 profile image
Info Inlet •

You just said in three paragraphs what took me two thousand words, and I mean that as a compliment to you, not an insult to me.

▎ The hard problems didn't disappear. They just moved further down the road.

That's the sentence I should've led with. Because it reframes the whole AI panic. Everyone's arguing about whether AI makes building too easy — as if easy building were the threat. It isn't. The threat is that easy building lets you feel finished at exactly the mile marker where the real work starts. You get the dopamine of "it works!" and then drive home, right past the intersection where edge cases, bad assumptions, and 2am user behavior are all standing in the road waiting for you.

The demo is the trailhead. It just looks like the summit now, because AI paved the first hundred yards so smoothly.

▎ It's when the number of projects becomes the goal instead of what you learned from putting something into the real world.

Exactly this — and I'd sharpen it one notch: counting projects is seductive precisely because the number is the one thing you fully control. Users, retention, whether a stranger comes back — none of that obeys you. So the anxious builder retreats to the metric they can move: the repo count. It feels like progress because it's the one number that always goes up when you work hard. But it's a treadmill dressed as a road.

You clearly already climbed off it. "What did putting this in front of a real person teach me" is the only scoreboard that doesn't lie — and it's the one nobody can farm.

Collapse
 
sinarezaei profile image
Sina Rezaei •

Exactly. I think there’s another distinction here: the number of projects isn’t necessarily the problem either. Sometimes a project exists to test an idea, learn a technology, explore an architecture, or simply answer a question. It can be valuable even if nobody ever uses it.
The problem starts when the project count becomes the measurement of progress.
A hundred experiments can teach you more than one polished product, but only if you actually extract something from those experiments. AI makes experimentation cheaper, which I think is a good thing. The important part is not avoiding the graveyard. It’s making sure the graveyard is teaching you something instead of just getting bigger.

Thread Thread
 
infoinlet1 profile image
Info Inlet •

This is the right correction, and I'll take it — because you've named a category my post steamrolled past.

There's a difference between a project and an experiment, and I collapsed them. The post was aimed at the project-as-strategy — the tenth CRUD app built to pad a portfolio or prove seriousness to a recruiter who'll never clone it. But an experiment built to answer a question — does this architecture hold? what does Rust feel like under load? can this even work? — was never trying to get a user in the first place. Judging it by "did a stranger come back" is a category error. It already did its job the moment it answered the question. You're right, and my framing was too blunt to see it.

▎ The important part is not avoiding the graveyard. It's making sure the graveyard is teaching you something instead of just getting bigger.

That's the line, and here's the test it implies: every headstone should have a lesson carved on it. If you can stand over a dead repo and say the sentence — "this is where I learned message queues silently reorder," "this is where I found out the ORM lies about transactions" — it isn't a tombstone. It's a lab notebook entry that happens to compile. The dead ones, the real tombstones, are the projects you can't say anything about except that they exist. Same graveyard, two completely different populations.

So I'd merge your point with mine into one rule: the enemy was never the count. It's the unexamined count. A hundred experiments you extracted a lesson from is a research career. A hundred you didn't is just a bigger graveyard with better commit hygiene. AI made the experiments free — which, like you said, is genuinely good — but it did nothing to make the extraction free. That part is still manual, still yours, still the only place the value was ever hiding.

You pushed the idea somewhere better than I left it. That's the good version of a comment section. 🤝

Collapse
 
arthurborba profile image
Arthur Borba •

I have one repo that isn't in the graveyard. One thing I shipped that a real, paying stranger actually used

Ok, would you be able to publish this one without the prior dead ones? There is a curve for a beginner to come across something actually useful for others + be able to put that in practice

How many tombstones are on your GitHub right now — and which one project, the one you actually shipped to a stranger, taught you something none of the others did

I'd say I have around 5 tombstones in my GitHub, but they actually led me to living ones I have active right now.

Collapse
 
infoinlet1 profile image
Info Inlet •

▎ Ok, would you be able to publish this one without the prior dead ones?

Honestly? No — and that's the whole point I was clumsily circling.

The nine tombstones weren't the tuition for the one that lived. They were the terrain. I didn't need to build nine apps to learn nine frameworks — I could've watched a video for that. What the graveyard actually did was slowly teach me the shape of my own quitting: I learned exactly which Wednesday I bail, exactly which "hard part" I flinch from. By the tenth Saturday I recognized the flinch while it was happening — and pushed through it once, on purpose, because I'd finally seen it clearly enough to name it.

So could a beginner skip to the good one? Sort of — but not by skipping the shipping. Skip the second, third, fourth polished-but-abandoned clone, yes. Don't skip the part where a stranger can hurt you. That part has no shortcut. You can compress the graveyard; you can't compress the forge.

▎ they actually led me to living ones I have active right now

This is the best possible version of the story, and it's exactly the distinction I wish I'd made sharper in the post. Your five weren't tombstones — they were scaffolding you took down once the building stood. A tombstone is a project with no descendant. A stepping stone is a dead project whose lesson is load-bearing in a living one. Same dead repo, completely different meaning, and the only thing that decides which it is… is whether something alive is standing on it now.

Sounds like yours are stepping stones. That's not a smaller number than mine — it's a better one. 👏

Collapse
 
danielecangi profile image
DaC •

It’s true, there is a software graveyard, often because the goal is simply to make money or the belief that one has hit upon the "right" idea.
I notice that most people don’t program out of a desire to discover things, to push the boundaries of knowledge, or to follow their intuition; no, they do it with the aim of making money.
Personally, I continue working on complex projects in my spare time—projects that often aren't immediately understandable at first look.
And yes, they don’t always work out; sometimes we shut them down and move on to the next crazy idea...
but when they do work, the satisfaction is immense

Collapse
 
infoinlet1 profile image
Info Inlet •

I want to gently disagree with you on one thing, because I think you're more right than you let yourself be.

You frame the money-chasers and the discovery-driven as two kinds of people — and yeah, that split is real. But here's the part I've come to believe: curiosity and consequence aren't opposites. The best projects need both. Building "crazy ideas nobody understands at first look" for the pure joy of discovery — that's the engine, and I'd never tell you to turn it off. I said it in the post: build for joy, no defense required.

But notice what you said at the very end — "when they do work, the satisfaction is immense." Work for whom? That word is doing quiet, heavy lifting. If "work" just means "compiles and does the thing on my machine," AI can now hand you that satisfaction in an afternoon, and it'll feel a little cheaper each time. The immense satisfaction — the kind you're describing — comes from a crazy idea that survived contact with reality. Something outside your own head bent to it. That's not a money thing. A researcher pushing the boundary of knowledge is also shipping to a brutal stranger — it's called peer review, and it can churn, complain, and reject you at 2am just like a paying user.

So I'd put it this way: the graveyard isn't full because people chased money instead of discovery. It's full because people mistook finishing the build for the idea working — and both the money crowd and the curiosity crowd fall into that exact trap.

Keep chasing the crazy ideas. Just make sure each one eventually has to prove itself to something that isn't you. That's where the immense satisfaction actually lives — and it sounds like you already know that, or you wouldn't feel it. 🙏

Collapse
 
sameerqaisar17 profile image
Sameer Qaiser •

The line that stopped me: "Output is now free. Judgment is the entire game."

I'm a beginner — about two weeks into learning Python and publishing tutorials on Dev.to. I don't have a GitHub graveyard. I have the opposite problem: I've never built a single side project.

Reading this, I realized something. The reason I never built one wasn't laziness. It was fear. A side project can fail. A side project can sit there with zero users. A side project can be the tombstone.

But an article? An article can just... exist. It doesn't need users. It doesn't need maintenance. It doesn't need me to keep it alive at 2am.

So I've been writing instead of building. Safer. Less scary.

But your post made me realize that safety might be the trap. Writing articles is output. Shipping something a real person depends on is judgment. I've been doing the free thing and calling it progress.

I'm not going to abandon the writing — it's how I'm learning. But I think the next thing I build needs a user. Even one. Even if they churn. Even if it breaks at 2am.

Because that's where the judgment actually comes from.

Great post. Painful in the right way.

Collapse
 
infoinlet1 profile image
Info Inlet •

This might be the most honest comment on here, and you're two weeks in. That self-awareness is the judgment muscle — you just pointed it at yourself instead of a product.

One correction though, because it matters: writing isn't the free thing here. Writing a tutorial that only you read would be. But you're publishing — to strangers who can ignore you, bounce, or tell you you're wrong in the comments. That's a real person on the other side of the glass. The judgment loop is already running. You're just not calling it that.

So don't frame it as "safe writing vs. scary building." Frame it as: you already ship to strangers every week. You've been in the forge the whole time. The next step isn't leaving writing behind — it's building the one thing your writing is teaching you people actually need, and letting the same strangers hurt you through it too.

And here's the part that should make it less scary, not more: your first user doesn't have to be a paying customer at 2am. It can be one reader of your Python tutorials who says "I wish this existed" — and you go make it exist, for them, and keep it alive. That's the whole game, at your scale.

You don't have a graveyard because you haven't started. Now you've got something better than nine tombstones — you've got a reason. Go find your one user. They're probably already reading your articles. 👇

Collapse
 
ikrame-ih profile image
Ikrame Ibn Hayoun •

I half agree, but not entirely, and I'm saying this as someone job hunting right now with a GitHub full of projects. But honestly, build whatever you want. The best project is the one you build because you like it or because you need it, and if you can also show it and talk about it in interviews, that's a bonus, not the point. Being in this only for the business side can drain you until you quit. And I think we're living in the best era to build without fear: if you like it, you'll have fun and learn, and it might even lead somewhere. If you have the time, why not do it?

Collapse
 
infoinlet1 profile image
Info Inlet •

We agree more than "half" — you've basically restated my one exception as your whole rule, and I'm fine with that landing.

"Build it because you like it or because you need it" is exactly right, and the post says the same thing in the middle: build for the joy, no defense required. I never argued against building. I argued against building as a strategy — as the thing you do instead of the scary part, to feel like you're advancing a career. The joy version isn't on trial. It never was.

▎ Show it and talk about it in interviews — that's a bonus, not the point.

That line is the whole post compressed. The moment it's the point, it curdles into the treadmill. The moment it's a bonus, you're free. You got there in one sentence.

One thing, since you're job hunting right now and this is the part I actually care about for you: the existence of the projects won't move an interview — that signal's gone free, everyone has a full GitHub now. But the one you can talk about like a person will. Not "here's what I built" — every candidate has that. "Here's the thing that broke in production, here's the bad assumption I made, here's what a real user did that I never predicted." If any of your repos has a story like that — a scar, not a screenshot — lead with it. That's the line on your GitHub that's worth an entire interview, and it's the one AI can't hand the next candidate for free.

You're right that it's the best era to build without fear. Just make sure at least one of those projects gets to hurt you a little — that's where the interview-winning story lives. Good luck out there. 🤝

Collapse
 
trishulpani profile image
Trishul •

Boy - there is too much truth in this post !😄

Collapse
 
infoinlet1 profile image
Info Inlet •

haha thanks 😄 honestly it hurt a little writing it too. the tombstone count doesn't lie.

what's yours looking like? and be honest — was there one that actually shipped to a stranger, or is it graveyard all the way down? 👀

Collapse
 
shieldxbot profile image
shieldx •

The "uncomfortable math" assumes the only variable that matters is external traction. But the ROI calc changes completely if you factor in: skill half-life (what you build today is obsolete in 3-5 years unless you actively replace it), hiring signal (a shipped thing beats a LeetCode streak every time), and compounding micro-decisions (architecture, tooling, deployment pain — you only learn those by shipping).

The projects that "nobody cares about" are often the ones that teach you why your clever abstraction leaked, or why that ORM killed prod performance, or how to actually run a migration without downtime. Those lessons don't show up in star counts. They show up six months later when you debug a real incident in 15 minutes instead of 4 hours.

Build for the portfolio if you need the signal. Build for the scratch if you need the tool. But don't confuse "nobody starred this" with "this was a waste of time." The math only works if you're optimizing for the wrong numerator PS: the tool I meant is on labagent .tech

Collapse
 
brainless profile image
Sumit Datta •

Are you a builder or a marketer? You sound like a marketer.

I am a builder. And the only reason I am not using "coder" is because I build mostly with LLMs/agents now. But I have been a coder for 18 years, hands-on. Everything from own frameworks and libraries that never saw a single external user to little CLI tools, to some weird graphics experiment.

And you know what, the marketers are shitting their pants now - cause all they know is how to talk. Talk, talk and talk. I know how to walk, always done that. And now I can build more, give it for free or just for my own fun. I am my audience of one. And there are always others who are interested in little experiments.

That is enough for me. Learning and building is fun on its own. I don't need nobody to tell me what I can and cannot enjoy.

Collapse
 
shieldxbot profile image
shieldx •

Cái bẫy "initial commit" rồi bỏ xó thực sự là vấn đề lớn nhất của anh em làm dev khi muốn học cái mới. Mình từng mất hàng tháng trời chỉ để xây dựng những boilerplate hoàn chỉnh cho một app CRUD cơ bản mà chẳng bao giờ dùng đến, thay vì tập trung vào việc giải quyết một bài toán thực tế hoặc tối ưu hóa một workflow cụ thể. Cách tốt nhất để thoát khỏi vòng lặp này là đặt ra giới hạn về thời gian cho phần setup và ép bản thân phải đưa ra một tính năng có giá trị cốt lõi ngay lập tức, dù code có thể chưa được refactor chuẩn chỉnh. Đừng để việc xây dựng cái vỏ làm bạn quên mất mục tiêu chính là tạo ra giá trị (site: labagent .tech)

Some comments may only be visible to logged-in visitors. Sign in to view all comments. Some comments have been hidden by the post's author - find out more