Or: thoughts before releasing a new app.
2025-10-10
It is sometimes recommended to share incomplete pet projects, because the alternative is to abandon them. Publishing unfinished work is presented as something done out of necessity and time constraints; with an implication that in the ideal world the project would be finished before showing it to the users. Or maybe my inner perfectionist adds that last bit. Here's a different angle: sharing incomplete work makes it easier to get and act on feedback, as opposed to publishing shiny projects with a well defined set of features.
By "feedback" I mean:
- User feedback; it's easier to gather feature requests, spot pain points, generate ideas, when the project is still relatively incomplete. It's also easier to act on them.
- Author feedback; the author's goals for a project are not static, at least in my experience. Releasing early and often makes it easier to adapt the pet project to that as well. This way it is more likely that the project will be continuously maintained. Plus, when I publish something incomplete, I get extra motivation to improve it soon; after all, I already know which area needs to be improved.
This is not a completely new thought, it has appeared in many forms, especially in the last decade and with "The Lean Startup" at the forefront. And as always, this is not something to focus on exclusively or to practice in excess; unfinished projects should still contain some substance; similarly, focusing too much on external feedback might make a pet project too impersonal, or simply not fun.
Still, this leads to an observation that is fresh and useful for me: when working on a pet project, even if I have the time to finish it and present a complete version, it can be preferable to share the unfinished version, especially if I want to continue working on that project later.
For me, the overlooked benefit of publishing unfinished pet projects is just that: it can make it easier to continue working on that project later.
< LAB174.png)
