Comment by pezo1919

Yes and no.

I'd say if you have a set of features and a toolchain which enables you to build them then ofc go for it.

However that's not my usual experience with any of my projects even personal ones.

The thing is I don't know what I'm going to build, in the contrary, I am aware it will take several iterations to figure it out. Because of that I have to check out what is "out there" in the ecosystem to make sure I can change directions sometimes if I want to. I want to maximize my freedom in that niche. Because of that every time I have some additional information about the whole project (in which features come and go) it's an option to step back and reevulate existing possible solutions in my mind and go do some further research when necessary.

My experience is when parts are not thought out in a project then they will slow the entire workflow down over and over again.

Just build or just not to build: I think this is a wrong question. When start to build & how/what to research are much better I think - and with real examples its much more useful I think.

Eg.: I'm totally done with relational and document databases. To me it seems both suck hard so lately I am investigating graph dbs. No, I won't start a new project until stupid rigid schemas / migration problems / schemaless weaknesses (dupe) won't just go away.

Maintaining old shit is enough for me I really don't want a new broken system as technical/real life debt.

Ofc you can go out and build pages with jquery which do generate tons of money for you, but others will be able to do the same when they've figured stuff out. What then?