Imagine spending your weekend building something interesting.
Maybe a small weather application.
A tool that organizes your photographs.
A website that recreates the interface of an old computer.
Or a simple Python script that solves a problem nobody else seems to care about.
You spend hours experimenting.
Something breaks.
You fix it.
You learn something new.
And finally, the project works.
You're happy.
Then someone asks:
"That's interesting. How are you planning to monetize it?"
And suddenly, a perfectly enjoyable weekend project becomes a business discussion.
What's the target market?
What's the revenue model?
How will you acquire users?
Can you scale it?
Is there an investor opportunity?
I understand these questions. I'm a founder myself.
But I've been thinking about something lately.
Why does everything we build need to become something we sell?
We Have Turned Building Into a Business Competition
There was a time when building software was also a way to explore technology.
You learned HTML because you wanted to create a website.
You experimented with Python because you were curious about automation.
You built a game because you enjoyed playing games.
You created a small tool because something bothered you and you wanted to fix it.
Not every project needed customers.
Not every experiment needed a market.
Not every repository needed thousands of stars.
Sometimes, the project existed for one reason.
You wanted to see whether you could build it.
But the conversation around software development has changed.
Today, we frequently hear:
Build in public.
Launch an MVP.
Find paying users.
Create recurring revenue.
Turn your skills into a business.
There's nothing wrong with any of these ideas.
In fact, I believe they're valuable when you're intentionally building a company.
The problem begins when we start applying the same expectations to every experiment.
A Side Project Has a Different Job
A startup exists to create value for customers through a sustainable business.
A side project doesn't necessarily have that responsibility.
It might exist to help you learn.
To explore an unfamiliar technology.
To understand how something works.
To test an unusual idea.
Or simply to enjoy the process of creating something.
Consider someone building a tiny operating system as a learning exercise.
It probably won't compete with Linux or Windows.
Does that mean the project has failed?
Of course not.
The developer might learn more about memory management, process scheduling, and hardware than they would from months of watching tutorials.
Or consider someone building a small application that visualizes sorting algorithms.
There are already hundreds of similar tools.
From a business perspective, the idea might appear unoriginal.
From a learning perspective, it could be incredibly valuable.
A project's value isn't always measured by how many people will pay for it.
Sometimes its value is what it teaches the person building it.
AI Has Made This Pressure Even More Interesting
AI has reduced many of the barriers to creating software.
You can prototype an idea faster.
Generate boilerplate.
Explore unfamiliar frameworks.
Build interfaces.
Experiment with APIs.
That's wonderful.
But there's a strange consequence.
Because building has become easier, the pressure to produce something commercially useful can become even greater.
Why build a small experiment when you could launch an application?
Why learn a framework when you could create a SaaS product?
Why spend time exploring an idea when you could turn it into a business?
I think this misses something important.
Just because technology makes an opportunity possible doesn't mean we have to pursue it.
We should be able to experiment without having to justify every hour through a potential financial return.
Otherwise, curiosity slowly turns into another performance target.
Sometimes the Most Interesting Projects Are Completely Impractical
Think about the projects developers enjoy sharing.
Someone creates a programming language for fun.
Someone builds a robot that performs a ridiculous task.
Someone turns a terminal into a game.
Someone recreates an old interface.
Someone connects a sensor to a Raspberry Pi just to understand how it works.
These projects may not solve enormous business problems.
But they can be fascinating.
They encourage experimentation.
They teach unexpected lessons.
And sometimes they inspire other developers to try something new.
Not everything useful has to begin with a commercial purpose.
In fact, some of the most interesting ideas emerge when people are free to experiment without knowing exactly where the results will lead.
That's one reason I don't want us to lose the culture of building things simply because they seem interesting.
I Believe in Distribution. But Not Everything Needs Distribution.
This is where my perspective as a founder becomes important.
I've written before about how developers can build global influence without working at Big Tech.
I believe in sharing knowledge.
I believe in building relationships.
I believe developers should understand how to reach people with their work.
And when you're building a company, distribution is absolutely essential.
A product that nobody discovers will struggle, regardless of its technical quality.
But here's an important distinction.
A project you build for learning is not the same as a product you're building for customers.
The first doesn't need a marketing strategy.
The second probably does.
The first can succeed even if only one person uses it.
The second needs a sustainable reason to exist in the market.
Both are legitimate.
The mistake is pretending they're the same thing.
The Hidden Cost of Monetizing Every Idea
Turning an experiment into a business changes your responsibilities.
Suppose you build a small application over the weekend.
You enjoy the process.
You share it with a few friends.
Everything is simple.
Now imagine deciding to commercialize it.
Suddenly, you may need:
- customer support and documentation
- billing and payment systems
- security and privacy considerations
- reliable hosting and monitoring
- maintenance and updates
- marketing and customer acquisition
- financial and operational planning
None of these responsibilities are inherently bad.
They're part of building a real product.
But they can fundamentally change your relationship with the project.
Something that previously gave you creative freedom can become another obligation.
And sometimes, the financial opportunity isn't large enough to justify everything that comes with it.
A side project can be successful precisely because it remains a side project.
We Shouldn't Confuse Learning With Wasted Time
Imagine a developer spending two weeks creating a small game.
They don't sell it.
They don't launch a startup.
They don't gain a large audience.
But they learn about state management, event handling, rendering, and application architecture.
Was that time wasted?
I don't think so.
The project might make them a better developer.
It might introduce them to a new field.
It might help them discover something they genuinely enjoy.
And that learning could become valuable years later in a completely different context.
Not every return on effort is immediate.
Not every useful skill can be assigned a price.
Sometimes the most valuable outcome is that you understand something today that you didn't understand yesterday.
There's Nothing Wrong With Wanting to Build a Business
I don't want this article to sound anti-startup.
Quite the opposite.
Building a business is one of the most challenging and rewarding things someone can attempt.
I know that entrepreneurship requires discipline, patience, judgment, and an enormous amount of work that happens outside the technical product.
If your intention is to create a business, you should think about customers, distribution, pricing, competition, and financial sustainability.
You should validate demand.
You should understand the market.
You should ask whether the problem is valuable enough for someone to pay to solve it.
But you don't need to apply that process to every interesting idea.
I wrote in I Think Developers Are Building Too Much Software about the importance of knowing what deserves to be built.
There's another side to that argument.
Sometimes something deserves to be built even when it has no commercial value.
Because the purpose might be learning, creativity, or enjoyment.
And those are perfectly valid reasons.
Maybe We Need Two Different Definitions of Success
For commercial products, success might mean:
Are customers using it?
Does it solve a valuable problem?
Will people pay for it?
Can the business sustain itself?
For personal projects, the questions can be different.
Did I learn something?
Did I solve an interesting challenge?
Did I enjoy building it?
Would I like to explore this technology further?
Did it make me a better thinker or developer?
We need both kinds of work in the technology community.
Commercial projects create economic opportunities.
Personal experiments create space for curiosity and discovery.
And occasionally, something built purely out of curiosity becomes a useful product.
That's wonderful when it happens.
But it doesn't need to be the expectation.
My Advice to Developers: Keep Something Just for Yourself
If you're a developer, I would encourage you to have at least one project that doesn't need to prove anything to anyone.
No business model.
No growth target.
No investor pitch.
No pressure to make it viral.
Build something because you find it fascinating.
Experiment with a language you've never used.
Recreate something from your childhood.
Build a useless little tool that makes you smile.
Explore a difficult algorithm.
Try combining two technologies that don't normally belong together.
You might discover something useful.
You might build something terrible.
You might abandon the project halfway through.
That's fine.
Not every experiment needs to become a success story.
Sometimes the freedom to fail without financial consequences is exactly what makes experimentation worthwhile.
The Best Part of Building Might Be the Building Itself
I spend a lot of time thinking about technology, business, and the future of AI.
I believe technology should solve meaningful problems.
I believe founders should think seriously about distribution and customer value.
And I believe developers should recognize the opportunities their skills create.
But I also believe we need to preserve something simple.
The joy of creating things.
Not because someone will pay us.
Not because it will improve our personal brand.
Not because an algorithm will reward us.
But because solving a problem, understanding a system, or making an idea come alive can be satisfying in its own right.
We don't have to turn every interest into income.
We don't have to turn every experiment into a product.
And we certainly don't have to turn every side project into a startup.
Sometimes you can build something, learn something, smile at what you've created, and move on.
That's not a missed business opportunity. That's a perfectly good reason to build.
Top comments (3)
Why developers need room to experiment, learn, and build without turning every idea into a business
This is a useful distinction, and the part about the tiny operating system is the best example in it. Learning memory management by building one is real education even if nobody ever runs it. Nobody owes a weekend project a business model.
There is one place where I would draw a second line, though, and it is the job hunt. A project built for learning answers to you. A project shown to a hiring manager answers to a stranger, and strangers cannot judge effort they cannot see. That is where beginners get stuck: they have genuinely learned things, but nothing they can walk someone through and have graded.
No IT certification is needed to start. What carries weight is work someone else already judged: a real ticket or incident, the call you made, and what happened next, recorded so it checks out. The simulated shifts at getonthejob.com are built around exactly that: real tickets and incidents, graded like a real team, so the learning you did on your own turns into a verifiable work record. The free shifts are a good way to feel what that kind of judged work looks like, without turning your curiosity into a product.
The two definitions of success do the heavy lifting here. A sorting visualizer judged on what it teaches reads very differently from the same project judged on whether anyone pays for it.