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

I use an org-mode text file for simple project management. It has two sections: Todo and Release. The Todo section has the todo items; some are marked as #feature for high level functionality and as #bug for bugs. Todo's have a life cycle of TODO/WORKING/DONE/CANCELED. When a release is made, the done items are moved to the Release section. A release has two lists: Feature and Changes. The done features are moved under the Feature list and other done items are moved under the Changes list. The Todo section manages the current tasks and the Release section captures the history.

Add new feature or ideas to the end of the todo list. Add related todo's under a feature line. Add bugs as they are found. The order of the todo items is the priority. Move them around as needed. When canceling a todo, record the reason, so in case if it comes up again, you have a record of decision. That's it. It's pretty simple.

Below is a sample from one of my side projects (solo dev).

    * Todo
    ** DONE Filter out Export Panel page when doing session snapshot.
    ** DONE Add command "Optimize Tab Favicon" on the Utilities tab in Preferences.
    ** DONE #BUG cancelled dialog causes double event firings on the next dialog action.
    ** WORKING #FEATURE dark theme mode support.
    ** WORKING Add light theme, dark theme, and default theme.  Refactor CSS.
    ** TODO Apply theme to components.
    ** TODO #FEATURE session push to remote devices.
    ** TODO #FEATURE Localization.

    * Release 2.11, 04/02/2019
    ** Feature:
    - #FEATURE Package the custom Web Components with the addon distribution.
    ** Changes:
    - #BUG All the dialogs are not showing, due to the missing custom components in the distribution package.
    - #BUG Error when a pinned tab is restored with the 'discarded' flag set, for lazily loading.
    - Restore active, reader-mode, or pinned tab as fully loaded tab, no lazily loading for them.

    * Release 2.10, 03/14/2019
    ...

    * Release 2.9, 02/21/2019
    ...

I tend to use a simple txt, it is always open on my editor, and I put there the TODO, or any bug I found. If I have to persist this information I tend to use github issues and use a PR flows, but in general a txt is more than fine. I've been working like that for 6 months in a row, alone. And I have to tell you when I'm tired of backend programming I move to the frontend , doing some visual adjustments, just for fun and mental health, then I switch back to the backend and so on, also this cycles are switched by testing, design, programming, flow design etc...

I tend to use a simple txt, it is always open on my editor, and I put there the TODO, or any bug I found, markdown format. If I have to persist this information I tend to use github issues and use a PR flows, but in general a txt is more than fine, just use that. If you get fancier than that I can assure you will get dizzy on tools. I've been working like that for 6 months in a row, alone. And I have to tell you when I'm tired of backend programming I move to the frontend , doing some visual adjustments, just for fun and mental health, then I switch back to the backend and so on, also this cycles are switched by testing, design, programming, flow design etc...

I have make and CMake templates for C and MSVC C++ projects, respectively, and I create a Sublime Text template with a todo.txt for each project. I tend to only use VS for debugging, as it's easier to link SDL, Lua and other libraries through a CMake build than the Visual Studio UI.

Yes