No More Forever Projects

No More Forever Projects

After nearly 20 years in development — from raw PHP days to modern full stack workflows — I fell into a familiar trap: the forever project.
Whenever I launched something on the side, I’d wrap it in grand promises. “This tool will be actively maintained.” “This blog is a long-term effort.” “This framework might turn into a product someday.”

I believed that commitment gave my projects legitimacy — like if I didn’t promise longevity, they weren’t worth doing. It felt like giving them gravity: something to pull attention, users, maybe even traction.

But the more projects I promised to maintain “forever,” the more I felt boxed in. Maintenance became obligation. Updating dependencies turned into guilt. And eventually, the passion that sparked the project got buried under the weight of keeping it alive.

The Trap of Obligation

I started asking myself: Why do I feel the need to make these promises?
And the uncomfortable truth was: I didn’t trust myself to follow through unless I created artificial pressure. If I didn’t declare my intentions publicly, I was afraid I’d just drop the idea altogether.

But here’s what experience taught me: Obligation doesn’t scale. Guilt is not fuel.
None of my side projects were ever saved by the weight of a promise. And most of the code I’ve been most proud of? It came from experiments — not lifelong commitments.

All those old repos gathering dust? They’re not failures. They were finished, just not in the way I imagined at the start. But I never gave myself permission to treat them that way — so I just carried the mental load.

From Forever to Finished

A fellow dev once told me:

“No more forever projects. Build things as experiments. Launch them, document them, and let them go.”

That single line reshaped how I approach everything. Now, when I start a side project, I scope it like a sprint: small, focused, with a clean end. I write docs, wrap it with care, and move on.
If people love it and it needs more? I can choose to continue. But it’s a choice — not a chain.

Funny thing is, the stuff I treat as one-offs? Those are the things that stick.
They get forked. They get reused. And sometimes I even circle back to iterate on them. But it’s on my terms.

By letting go of permanence, I’ve found more consistency, less guilt, and — ironically — more longevity in the things I build.

Michał Tajchert
Michał Tajchert

Born in Poland, Michal has over 18 years of experience as a software engineer. With a specialty in cyber security, Michal has become an expert on building out web systems requiring bank-level security standards. Michal has built platforms for financial services firms, hospital chains, and private jet companies.

Articles: 38

Leave a Reply

Your email address will not be published. Required fields are marked *