Stop-and-start development is completely normal when you introduce a lot of project tooling and it's new and shiny. For this reason, projects run by a solo dev

Stop-and-start development is completely normal when you introduce a lot of project tooling and it's new and shiny. For this reason, projects run by a solo developer tend to use less tooling and process than team efforts; the friction introduced by each new step in the workflow is a major penalty. The solo developer can just opt to ignore all the cruft and use a cheap, lazy option, because there is no communication issue. This also presents a bit of a dilemma if your goal is to learn a workflow in order to get hired on a team using that workflow, because you will feel like you are making nothing interesting or noteworthy. Your best option is to temporarily change your mindset from "engineer building software" to "writer building documentation". The person documenting has to play detective and ask questions constantly. It takes them four times as long to do anything because they have to write down the steps and make it digestible. But each time they make progress and write down those steps, they set down a little roadway for people to drive over in the future. They also gain more credibility as an expert in the process.