Amen. I try to do things fairly rough and allow myself to quickly pivot if I’m feeling like what I’m building will take too long and there may be other more important tasks.

The one bit of process I do follow is I generally write up some quick notes about what I’m trying to achieve. What is the purpose of this feature (i.e. what is the customer goal or marketing goal) and then I write up how I’m thinking of solving it. That gives me enough context in case I revisit things later and forget why I even started it.

From there I usually think about the design (UI and architecture) and sketch out a bunch of things. I’ll go for walks and think about it a lot.

Once I have enough to code, I’ll make a todo list in a markdown file (usually the same one with the notes from earlier). I just keep checking off tasks in there and adding new ones.

Eventually I start getting most of the tasks done and often there’s enough to either just test it/ship it or not. I just go with a gut check as to whether I should add more polish or not, but I try to cut myself off once the main use case works and looks decent.

I usually test for a day or two before shipping.

This is how I coded up most of the recent features of my app. (See my profile for a link.)

To be honest, writing the features is the easy part. The hard part is marketing and finding users.

Sure thing but it's good to have at least a little something to prevent too much refactoring later.