My process feels much less like engineering and more like utter chaos, but it works for me. I start by defining the minimum viable product. Emphasis on minimum

My process feels much less like engineering and more like utter chaos, but it works for me. I start by defining the minimum viable product. Emphasis on minimum. It should be painfully minimal, and missing all sorts of features, but works roughly well enough to be a good litmus test. That's it. Then I build it. Based on the feedback / information gleaned from building the MVP, I often pivot. This frequently involves tossing some things out and rewriting other things. But generally, it means planning the next phase. Here, I ask, "What is the single most important thing I can do to make this project more useful for the intended users?" And that's what I design / build. Repeat indefinitely. [Edit: Documentation is sparse. I like to comment the top of each source file with a brief description of what it's for. If there's something really key to the project or that is reused a lot, I'll drop a readme into the same folder as the source, and document it the way I would an OSS library. Regarding prototypes, it takes a lot of discipline, but I always throw 100% of my prototypes away. In the past, I didn't do this, and I always regretted it.]