Haha given we worked at the same place, I'm not surprised you're immediately jumping into a design doc. I think it was drilled into everyone! Here are my thoughts on design docs + indie hacking: design docs for me are a mechanism to convince other people that my idea is good -- and they also serve as good documentation for future team members. That said, I personally don't find those docs useful when building on my own as I can just think about what I want to do and do it vs. having to convince anyone else that my idea makes sense. I don't have much of a problem with having the idea for the codebase/system design in my head and building from scratch based on that. Also, for db schema: it's so easy to change when you're the only developer on the project and you don't have any users yet, so I just add a migration with my rough idea for the schema and make changes as needed on the fly instead of writing down the most optimal schema in a doc.

Note: If I were to hire contractors or add a co-founder to the mix, I'd write up a few docs to get them up to speed, though it isn't the highest priority for now.

I think I follow a similar process to what you're describing:

1. First check if there are any competitors to the idea to see what kind of value I can bring that they aren't providing. In the case of SimpleOTP, it became clear that I could compete on price, privacy/openness/not selling user data, customizable integration compared to something like auth0, aws cognito, google/fb signin. I like to pick ideas that already have a market/some competitors as well - it's free validation of your idea to some extent.

2. Build a landing page to target people using the above research

3. Ask users for feedback on this site + indiehackers

4. Iterate on landing page and address all initial feedback

5. Set a signup goal: I usually wait for at least 10 signups before building anything. If a month is up and I don't have enough people interested, I move onto the next idea. Having launched a couple of these ideas recently, there is a pretty clear difference between an idea that has legs and one that doesn't -- my first idea had a few signups, maybe 5-6 but then completely stopped after a day or so. SimpleOTP has 20+ signups from just launching a landing page on indiehackers and I'm getting at least 1 random person per day that just happens to sign up after viewing the landing page (even though the landing page is in bad shape, I really need to improve it based on recent user feedback haha)

6. Build the initial version of the product while sharing progress with users on Twitter as I'm doing it -- if my idea supports "no code" even better. For PrintSwarm, I just used a landing page builder + dragged and dropped a stripe component onto the screen + had orders sent to my email. That won't work out perfectly for all ideas though, i.e. it's near impossible to do a "no code" version of an authentication product for example

7. Try to get people to pay by launching on more "serious" platforms like ProductHunt, HackerNews, etc and emailing all the users that signed up on your landing page with a payment link. I think some people launch on ProductHunt earlier, but the bar for a good product is high these days, so I like to wait to post on PH until I have something that at least works and not just a landing page.

You give the obstacle to the answer: "Need to decide whether...."

Decide what the goal is.

Make it 'smart', you'll know that probably from the big tech env...

Then, do a stand-up, estimate things..., perhaps a pre-mortem, etc :)

If it's not a ridiculously complicated project, I like to build stuff immediately. I'm trying to avoid the situation where I lose enthusiasm for a project because it's not something 'real'. The coroner says most of my projects have died this way.

So I'm trying to get something out in a weekend this time around.

I'm not doing anything particularly complicated. The tech is just simple web dev stuff. For most stuff, I work in a pre-validated market with lots of competitors. I'm not exactly betting the entire house on one bet working off either.

My next project is just something fun and useful, without much thought for monetization.

Ideally, you have boilerplate with all the plumbing + apis for shared code between projects with analytics, payments, auth, etc (something like shipfa.st/ but for your own preferred stack) and try to cut corners by using BaaS/CMS/UI Templates/same tech stack every time/paid solutions.

This is what I'm trying to do for upcoming projects. Hope it helps.