Over the years, I have started far more projects than I have abandoned. At least, that is how it appears from the outside. There are repositories, websites, research papers, datasets, specifications, APIs and publications that continue to grow, often years after they were first created. Looking back, however, I can also see a long list of projects that quietly stopped evolving. They were never officially cancelled. They simply became inactive.
For a long time, I assumed this was a normal consequence of having too many interests. New ideas naturally displaced old ones and unfinished work accumulated as a result. That explanation felt reasonable until I noticed something unexpected. The projects that continued were not necessarily the most exciting or ambitious. In many cases, they were simply designed differently.
That realization changed how I think about side projects. The question became less about generating better ideas and more about creating projects that were capable of surviving beyond the initial excitement that inspired them.
Motivation Is an Unstable Foundation
Many discussions about side projects focus on motivation. The assumption is that projects stall because people lose interest, become distracted or fail to stay disciplined. While those factors certainly exist, they never fully explained my own experience.
I rarely stopped caring about the subject itself. If I returned to an old repository or reread an unfinished draft months later, I usually found the idea just as compelling as when I started. What had disappeared was not interest but context. Picking the project back up often required remembering why certain decisions had been made, what remained unfinished and how the different pieces fit together. Rebuilding that mental model required enough effort that postponing the work became easier than continuing it.
This is a subtle but important distinction. Motivation tends to fluctuate but friction accumulates. Every decision left undocumented, every structure that only exists in memory and every project organized differently increases the effort required to return later. Over time, that effort becomes the real reason progress slows.
I gradually stopped thinking about stalled projects as failures of discipline. Instead, I began seeing them as systems that had become unnecessarily difficult to resume.
From Individual Projects to an Ecosystem
One of the most significant changes I made was abandoning the idea that every project should stand on its own.
Earlier in my career, I tended to treat each repository, website or publication as an independent destination. Every project needed its own purpose, identity and roadmap. While that approach worked for a while, it also meant that every new idea introduced another isolated system to maintain.
Today, I think about projects very differently. They are parts of a larger ecosystem rather than independent efforts competing for attention.
A research paper might identify questions that eventually become an open dataset. That dataset may expose gaps that lead to a software library or specification. Documentation written for one repository often becomes the foundation for a handbook, while ideas explored in a blog post frequently evolve into more formal research months later. Rather than moving from one disconnected project to the next, the work continually reinforces itself.
This interconnected approach has made individual projects more sustainable because they rarely exist in isolation. Progress in one area naturally creates opportunities elsewhere. Instead of asking whether a single repository is successful, I find it more useful to ask whether it strengthens the broader body of work that surrounds it.
Scope Determines Sustainability
Ambition is often celebrated in side projects but ambition without boundaries creates its own problems.
It is surprisingly easy to design a project whose imagined future version is so comprehensive that meaningful progress always feels incomplete. Large goals become difficult not because they are impossible but because there is no obvious place to stop, publish or pause. Every unfinished feature begins to feel like evidence that the project is not yet ready.
I have become much more deliberate about scope as a result.
Rather than attempting to solve an entire subject within a single repository or publication, I increasingly prefer building smaller components that can grow independently while still fitting into a larger framework. This approach does not reduce the overall ambition. If anything, it makes larger ambitions more realistic because progress becomes measurable and repeatable instead of overwhelming.
The objective is no longer to build one comprehensive project. It is to create a collection of focused projects that complement one another over time.
Infrastructure Compounds More Than Ideas
One lesson I did not expect to learn is that infrastructure often creates more long-term value than the projects it supports.
When I look at the work that has become easiest to maintain, it is rarely because the ideas became simpler. Instead, it is because the surrounding infrastructure improved. Consistent repository structures, documentation templates, publishing workflows, shared design systems and repeatable release processes all reduce the number of decisions required before meaningful work can begin.
None of these improvements are particularly visible. Readers rarely notice them and they are unlikely to become the centerpiece of a portfolio. Yet they quietly influence every future project.
The effect is cumulative. Every hour invested in making future work easier continues to pay dividends across dozens of repositories, articles, datasets and publications. By contrast, constantly rebuilding the same foundations creates invisible maintenance costs that eventually slow everything else.
I increasingly think of infrastructure as a long-term investment rather than overhead. It rarely produces immediate results but it consistently improves the pace and quality of future work.
Designing for Continuity
Another change has been reconsidering what success actually looks like.
Many side projects are evaluated as though they should eventually reach completion. While that may be appropriate for some forms of work, it does not accurately describe many of the projects I care about most. A handbook continues to evolve. A specification receives new versions. A dataset expands. A publication grows article by article. These are not projects that end so much as projects that mature.
Once I accepted that distinction, my priorities changed.
Instead of optimizing for launch dates or feature completeness, I began optimizing for continuity. Could I return to this project six months from now and immediately understand its current state? Would someone encountering it for the first time understand its purpose? Does the structure make future contributions easier rather than harder?
These questions have become far more valuable than asking whether something feels finished.
Building for the Future Version of Yourself
Perhaps the most useful shift has been recognizing that every project has two audiences.
The first is obvious: anyone who eventually reads the article, downloads the dataset or explores the repository.
The second audience is the person returning to that work months or years later. More often than not, that person is the original author.
Good documentation, thoughtful organization, clear naming and manageable scope are not simply acts of generosity toward future collaborators. They are equally valuable for the builder who eventually needs to resume work after attention has moved elsewhere.
Looking back, I no longer believe that most side projects stall because people run out of ideas or lose interest. More often, they stall because they were never designed to survive ordinary interruptions. Life changes, priorities shift and available time fluctuates. Projects built around ideal conditions inevitably struggle when those conditions disappear.
What changed for me was not becoming more productive or discovering a better way to stay motivated. It was adopting a different perspective on what a side project should be. Instead of treating each one as an isolated destination, I began treating them as connected pieces of a much larger system, built gradually over years rather than completed in a single burst of effort.
That way of thinking has not eliminated unfinished work, nor should it. It has simply made it easier to keep returning, refining and connecting ideas over time. For long-term builders, that continuity is often more valuable than the excitement of starting something new.
