[AymanJabr]

Honestly, if you are a small/medium startup, just having things like: 1) Eslint (any comprehensive linter) 2) Clear enough instructions (or a framework) on where different parts of the application should go 3) Clear instructions on how the branches should be handled and merged 4) CI/CD on Pull Requests 5) Comprehensive tests on the core business logic (mostly on the backend). 6) Maybe some regression tests just to make sure that nothing on the frontend breaks

All pretty standard stuff, and you can set it up in a day, a lot of the boring work can be done by LLMs, so you won't have to waste a lot of time on it.

I find that just doing the above things gives a project enough stability, and it gives the developers enough courage to refactor with confidence and ship relatively fast.

At the end of the day Software Architecture is a craft, if a system is not working for you or your team (or you don't understand why you are doing something), then you want to look at changing it.

[Ocerge]

I currently work on a ~10+ year old project that has maybe half of this list, and if you _don't_ start this way, the toothpaste is near impossible to put back in the tube, and you're in for a world of hurt. If the early engineers don't work this way and the system makes its' way into production, then functional software + income is very difficult to override in the name of cleaning up messes.