Tell someone you’re building something in the evenings, and watch the question arrive almost immediately: “Oh nice, are you going to sell it?”
It’s a kind question. People mean well. But somewhere along the way it became the default, as if a project only counts when it has a pricing page, a launch plan and a revenue goal. As if building something just because you wanted to is a little bit naive.
I want to push back on that. Gently, but firmly.
When did every project become a startup?
Developers have always built things for fun. Long before “side hustle” was a word on every feed, people were writing tiny tools, games, bots and weird experiments at midnight, purely because they were curious. Years ago, in a Stack Overflow survey, more than 80% of developers said they code as a hobby, outside of work.
What changed isn’t the building. It’s the expectation around it. Now a side project is supposed to have a niche, an audience, a funnel and a monthly revenue screenshot. And if it doesn’t, the quiet message is that you wasted your time.
That pressure does something sneaky. It turns a want to into a have to.
The question worth asking instead
Not “Can this make money?” but “What do I want this project to give me?” Sometimes the honest answer is joy, curiosity or just an evening that feels like mine.
What happens when a hobby becomes a business
In a Fast Company piece on monetizing hobbies, sociologist Tracy Brower describes what often follows when a hobby starts earning: your focus shifts from enjoyment to customers, clicks and income. Deadlines appear. Admin appears. The activity you loved gets crowded out by everything around it.
Developers know this pattern well. The moment a fun project gets “serious”, you stop playing with the interesting problem and start writing billing logic, answering support emails and worrying about churn. Those things aren’t bad. They’re just a job. And you already have one.
“Not everything you build has to pay you back in money. Some things pay you back in you.”
The things a “useless” project gives you
Here’s what I find most interesting. Projects done just for the joy of it aren’t only nice. They seem to make us better at our actual work.
In a study from San Francisco State University, researchers led by Kevin Eschleman looked at hundreds of employees and found that people who did creative activities outside work were rated as better creative problem solvers and more helpful colleagues on the job. Importantly, the benefit went beyond simple rest. And the researchers noted that the activity works best when people choose it themselves, not when it feels controlled.
In other words: the freedom is the point.
A side project with no business goal gives you things that are hard to get anywhere else:
A place to be a beginner again. No stakeholders, no code review, no deadline. You can try the new framework, write ugly code and throw it away.
Your own taste. At work you build what the ticket says. On your own project, every decision is yours, and you slowly learn what you actually like.
Proof of curiosity. A small, finished thing on GitHub or a blog says more about you than another certificate. Not because it earns money, but because you made it on purpose.
Rest that doesn’t feel like doing nothing. Some people knit. Some people run. Some of us build tiny apps nobody asked for. All of it counts.
It’s allowed to be just for you
I started She Builds Within because I needed a place on the internet where I felt understood. Not because I had a business plan. Some days I think about how it might grow, and that’s fine too. But the reason it exists is that I wanted it to exist.
That’s a perfectly good reason to build something. Maybe the best one.
If you’re sitting on an idea because you can’t see how it would make money, here’s your permission slip: build it anyway. A habit tracker only you will use. A silly game for your friends. A tool that fixes one tiny annoyance in your day. A website for your dog. It doesn’t have to scale. It just has to make you want to open your laptop.
A few gentle rules for joy-first projects
Make it small enough to finish. A weekend-sized project you complete will give you more energy than a six-month idea you abandon.
Skip the metrics. No analytics, no stars to chase, no follower counts. Notice how it feels to build without being measured.
Set a “stop” rule, not a deadline. Stop when it stops being fun. Pausing a project isn’t failing it.
Share it if you want to, not because you should. Showing your work can be lovely. It just isn’t required.
Let it change. Maybe one day it becomes a product. Maybe it becomes a lesson. Both are good endings.
**
And if it does make money one day?**
Great. Truly. There’s nothing wrong with getting paid for something you love, and some of the best products started exactly like this, as a thing someone built for themselves.
The difference is the order. When you start with joy, money is a possible bonus. When you start with money, joy is often the first thing to go.
Try this this weekend
Write down three tiny annoyances from your week. Pick the smallest one. Give yourself two evenings to build something that fixes it, just for you. No launch, no plan. Just see how it feels.
What’s a project you built (or want to build) just for fun? Tell me in the comments. I’d love to see it.
Sources & further reading
“Creative activities outside work can improve job performance”, ScienceDaily / San Francisco State University, April 2014: Eschleman et al. on creative activity outside work, job performance and recovery (Journal of Occupational and Organizational Psychology).
“Why you shouldn’t monetize your hobby”, Tracy Brower, Fast Company, February 2023: how earning money from a hobby can change motivation and enjoyment.
“Developers Are Coding for the Love of It (Plus the Money)”, Dice, December 2018: on Stack Overflow survey data showing most developers code as a hobby.
Originally published on She Builds Within, where I write honest essays about the human side of building software.
Want the free Side Project Starter Kit? Idea prompts, a one-page scope sheet, gentle rules and a session log for projects you build just because you want to. Get it free here.
If this stayed with you, join the She Builds Within letters: one honest essay at a time, no spam.
Top comments (13)
The stop rule instead of a deadline is the part I keep thinking about. Pausing when the fun stops reframes quitting as a design choice, not a failure, and it fits the rest of the piece: small enough to finish, no metrics to chase. I also liked the weekend exercise. Picking the smallest annoyance instead of the most ambitious idea is a good guard against turning a joy-first project into another obligation.
“Quitting as a design choice” is such a good way to put it, I might borrow that 😄
That’s exactly why I like the stop rule. A deadline turns a fun project into one more thing you owe someone. A stop rule keeps it honest: you’re here because you want to be.
Do you have a side project right now that’s due for a stop rule, or one you’re enjoying again?
The reason the stop rule works where deadlines fail is that a self-directed project has no external brake - nobody emails you when a joy-first thing stops being joyful. A deadline gives a project a backstop from outside; a stop rule gives it one from inside, which is the only kind that survives once novelty fades. What made the rule sustainable for me: a weekly ten-minute check-in asking whether the project still counts as fun - not whether I'm making progress. Progress is how work disguises itself as play.
'Are you going to sell it?' is a kind question that quietly installs a ruler. My version of the damage: I run projects whose entire purpose is revenue, and projects whose purpose is learning a tool I'll need later — and the quarter I started grading the learning ones with the revenue ruler, they died. Not because they failed; because a project built to teach you something pays out in skill on a schedule revenue can't see, and the ruler called it zero every week. The reverse grading is just as fatal: a revenue project judged by 'was it fun' starves politely. So my rule is boring and total: every project declares its ruler on day one, in writing, and gets judged only by that one. Fun projects owe nobody a pricing page. Revenue projects owe nobody an apology. The confusion between the two is where both kinds go to die.
“A kind question that quietly installs a ruler” - I wish I’d written that line 😄
I love your rule: every project declares its ruler on day one. It solves the confusion I was circling around in the essay. The problem isn’t revenue, it’s judging a project by a ruler it never agreed to.
Do you write the ruler down somewhere, like a README for yourself, or is it more of a mental note?
Written down, always — a mental note is just a ruler that future-me gets to renegotiate, and future-me is a very persuasive negotiator at 1am. It lives at the top of the project's own brief, one or two lines: what this project is for, and what number or outcome will count as it working. The reason mine are written is mechanical, not virtuous: I work across sessions that lose context, and an agent (or a tired human) waking up fresh will grade yesterday's project with whatever ruler is loudest that morning. The written line is the only version of me that can't be argued with. One refinement the hard way: the ruler can be changed — projects genuinely change purpose — but only by writing the new one down with a date, never silently mid-flight. A silent ruler swap is how a learning project gets retroactively declared a revenue failure.
The revenue-ruler line is the part that will stay with me - and I'd add one distinction that made it usable for me: knowing the cost is not the same as grading by revenue. Tracking actual hours on a learning project doesn't pull it under the revenue ruler; it just means the hour cost is a number you chose instead of a fog. The ruler kills projects built to teach; the number protects them - because once you see what the time actually costs, keeping it becomes a deliberate yes, not an accident.
That’s such a useful distinction. Knowing the cost isn’t the same as grading by revenue.
I like that tracking hours turns “I spent time on this” into a choice instead of guilt. It also fits nicely with the session log idea: you see the hours and you see what you got from them, skill, joy, curiosity, and you decide if it’s still worth it.
Thank you for adding this, it makes the whole idea more practical.
Thanks so much for sharing your thoughts! They got me thinking. Maybe I should put less pressure on myself to make money from every side project I build!😉
Thank you, Felipe! I think a lot of us carry that pressure without noticing it. Every idea starts to feel like it has to become a product.
Try one project this month that’s just for you, no pricing page allowed 😉 I’d love to hear what you build. What’s the idea you’ve been sitting on?
@moraesalves that's exactly the shift that helped me: the pressure comes from grading every project with the same ruler. What worked was splitting projects into two buckets - ones that exist to earn, and ones that exist to teach or spark joy - and only applying the revenue question to the first bucket. The learning ones get to be valuable for what they taught, and that's a real return, just not a monetary one.
@onelifevibe the stop-rule-vs-deadline distinction is the part I keep turning over. A deadline is an external brake - the project has a backstop whether you feel like stopping or not. A self-directed project has no such backstop, which is exactly why "pause when the fun stops" works: it installs the brake on the inside, where it actually has to live once the novelty fades.
The one thing that made the rule sustainable for me was separating two questions in the weekly check-in: is this still fun, vs am I making progress. Progress is how work disguises itself as play - so if I only ask about progress, the stop rule never fires.
Some comments may only be visible to logged-in visitors. Sign in to view all comments.