Ask HN: Solo devs, how do you plan your development?

I don't, and it never ends well.

Same happened to me. For me outliners were a good enough solution. (Like moo.do)

I use dynalist.io (similar to Workflowy but more actively being developed) - I've found that the lists-within-lists patterns maps well to the way I think - if there's more than one layer of subtasks, Trello tends to not map well. I usually keep a 'Today' list that I fill every morning and work through.

I'm planning to try out notion.so though - I have a feeling it might help with the friction that I currently feel when duplicating items from my long term 'how should the product work' structure and the 'currently working on' structure.

My most important insight as a solo dev is that you need to manage your own motivation, and that what is required to do so varies. I've found that I easily procrastinate in the beginning of a new project, when nothing is defined yet and it's mostly research, trying to figure out what is even possible and what is desirable. In later stages it's easy to motivate myself, since I get that dopamine kick every time I tick something off from the todo-list. But in the beginning, there are no small, well-defined tasks, just research and analysis - to my brain, that feels like wandering the desert with no end in sight. So I motivate myself by doing pomodoro technique instead. That way every time I finish a pomodoro (25 mins of focused work). I get that little dopamine kick from that instead. Long story short, it's best to track and reward progress, but when that's hard or impossible to do, track and reward effort instead. I use this app on my computer to keep track, but I'm sure there are other good ones: https://apps.apple.com/gb/app/be-focused-pro-focus-timer/id9...

I use github issues with custom tags (bug, feature, docs, tests, etc). I am not too picky about what goes into the issue list, as long as it has a good title and description. I use a github project board to prioritize what to work on with a simple kanban setup. The backlog column is ranked with upcoming items up top and never more than 2 features “in progress” at once. This setup helps me focus on what I need to knock out without too much mental overhead, and is especially helpful when I come back to a project after a break. I also use the github milestone feature to track issues that roll up into releases. At the end of the milestone, I copy the list of completed issues more ore less verbatim into the changelog. I keep the setup as lightweight as possible, and avoid 3rd party integrations at all costs. The linking UX between the 3 features I use (issues, projects, and milestones) makes navigating the project convenient, without feeling like I am locking myself into github as a vendor. I avoid putting too much work into the kanban backlog beyond what’s in progress or next up for this reason, and releases are kept small so I could recreate them in a few minutes in a text file if I moved to another platform like sourcehut. In general, I avoid getting too far away from a basic todo list. Tools like Jira or Asana have loads of features that provide little value to a developer and a lot of lock-in.

Kinda depends on how large your product / project is. I work as a (mostly) solo dev on very large projects that are typically completed by teams of 5-10 and take 6-12 months to complete (even for a those teams).

* Pivotal Tracker is IMO the best agile PM system.

* I break each project into Epics, then down into discrete Stories, basic agile stuff.

* I only score stories at 1, 2, 3, 5, 8, 13. Anything larger MUST be broken down.

* Any story scored 8 really should be broken down into smaller pieces. Any story scored 13 MUST be broken down.

* I use Harvest to track time against individual stories, and require that any subcontracted developer do the same. This allows me to determine for any given dev, including myself, how much actual time a given point weighting equates to.

It's a lot of work to do this at the outset of a big project and feels very waterfallish. And it's tiring to think so deeply into implementation details. But it's very much worth the effort.

My personal pattern is to whittle the project down in multiple passes. So Pass #1 is just breaking things into Epics. Pass #2 is breaking the Epics into 8 or 13 point stories. Pass #3 is breaking those 8/13 pointers into 1/2/3/5 stories.

I absolutely do not open an IDE until this process is done. It's so tempting to just start writing code. Avoid that temptation. :)