Side projects and open source: what they add to your career and their real cost

A few years ago I published a small library for the PHP community: InitPHP. I originally wrote it to make my own work easier, then shared it as open source. That process taught me something no article on side projects had fully conveyed: the return and the cost are both real, and they happen at the same time.

Looplio is a different dimension entirely — a fully self-owned product, a SaaS I run solo with commercial goals. The contrast between the two makes a useful reference point for understanding what a side project actually adds to a career.

Return: a space to learn freely

In a day job there is a large codebase; changes are made carefully, technology choices require discussion, dependency updates get stuck in testing pipelines. That is right and necessary — but it constrains the pace of learning.

A side project is where those constraints do not exist. You can try a new language, pick a different architecture, answer the question “I wonder if this would work” with real code. The cost of being wrong is low. That freedom provides a different learning rhythm from the careful, slower environment of a day job.

While building InitPHP I studied the depths of PHP — its type system, trait usage, class design — with a rigour that would not have been possible in a production codebase. With Looplio I learned mobile development using React Native and Expo; there was no mobile work in my day job.

Return: portfolio and visibility

Being able to say “you can look at this project” during a hiring process or a consulting conversation is a powerful thing. You cannot link to the code at your employer; you can link to your own project.

Open source adds an extra dimension here: a project that people actually use, report issues against, and contribute to. That demonstrates not only technical capability, but also writing code knowing someone else will read it, tracking issues, and documenting the reasoning behind decisions.

Return: network

Another developer who starts using your library. Someone who files an issue. A contributor. These connections grow organically and show up in unexpected ways over time — conference introductions, referrals, open role announcements — most of them flowing through those connections.

Looplio runs a build-in-public process: I share what I am building, which decisions I made, and why. That is its own form of network building; it creates intersections with people across different fields.

The real cost: time

Every open source library has an invisible budget: cutting releases, responding to bug reports, reviewing pull requests, keeping documentation current. None of that time is paid; the career return exists but is neither immediate nor predictable.

I underestimated this at the start. “How long can cutting a release take?” — a few hours if nothing is large. But when you have more than one project, those hours accumulate fast. And the day you spend an entire weekend on a library release, you understand clearly that this is a genuine time investment.

The real cost: attention

Closely related to time, but more insidious: divided attention. When you are thinking about a project in your day job and you also have an active side project, part of your mind is always there. Background thoughts like “I need to look at that bug too” or “don’t forget to make that change for InitPHP” run quietly in the background.

The cost of that cognitive load does not measure in hours, but it is real. Especially when there is more than one active project.

The real cost: maintenance burden and the pressure to “open source everything”

The community carries an expectation: “a good developer contributes to open source.” That pressure is real. But let me say this plainly: you do not have to open-source everything you write.

A library can exist without being open source. Your internal tools, your experimental projects, things you have not finished yet — you do not have to publish them. Listen to your own motivation, not the pressure from the community.

I made InitPHP open source because I genuinely believed it would be useful to others; and it was. I keep Looplio closed because it is a commercial product. Both are conscious decisions.

When to finish a project, and when to archive it

Projects you no longer maintain but have not deleted carry their own burden: questions arrive about outdated dependencies, issues are opened, people ask “is this still active?”

The archiving decision comes with these questions: Has anyone actively used it in the last six months? Am I still maintaining it? Have better alternatives appeared? If you answer all three with “no” or “yes, yes, yes” respectively, archiving is an honest call.

Being able to do this early gives both you and your users clear, honest information.

Distinguishing whether a side project is a tool or an escape

This question is hard to ask but worth it: is this side project genuinely about learning or building something, or is it about escaping the frustrations of the day job?

Both happen from time to time. But a side project that is an escape drains you; one with genuine motivation feeds you. Feeling the difference sometimes requires giving an honest answer to the question “why am I doing this?”

I ask myself that question regularly. When the answer changes, how I approach the side project changes too.