Hiring is like a code base, you have to have the right abstraction at the right time. Starting out, better everything be a concrete implementation, that is everyone is directly responsible for making things work.
Next is what I found most people doing differently from my ideal - abstract and refactor base on your existing implementation, not because of some framework doing it, nor because the previous project did it this way. Do you need a data access layer, a library, a folder, to talk to database where the first implementation was just storing things as a variable? You probably need a database and plain SQL. Do you need site reliability engineer to keep your site online while your traffic all comes from friends? Do you need a QA for testing? Or do you need a product manager where, as a founder, the value proposition has yet to be proven? How often do you see a code base spinning up all the folders/empty files because "we may need it". And how often when you hire someone, they spin up various incarnation people * time like teams, sprints, squad, function, BEFORE understanding the current implementation. This is why you hire the wrong people. And you know it only 1 year down the road. Wrong abstraction. Using framework has its appeal, where a cookie cutter solution mostly work. But it also has its limitation, bloat.
Once a wrong abstraction is in place, the more code/people depends on it, the more effort it takes to refactor
Btw, the most important point from OP's is the last one. Life is fragile, treat people well. That's more important than all the three letter acronyms in the world.
Next is what I found most people doing differently from my ideal - abstract and refactor base on your existing implementation, not because of some framework doing it, nor because the previous project did it this way. Do you need a data access layer, a library, a folder, to talk to database where the first implementation was just storing things as a variable? You probably need a database and plain SQL. Do you need site reliability engineer to keep your site online while your traffic all comes from friends? Do you need a QA for testing? Or do you need a product manager where, as a founder, the value proposition has yet to be proven? How often do you see a code base spinning up all the folders/empty files because "we may need it". And how often when you hire someone, they spin up various incarnation people * time like teams, sprints, squad, function, BEFORE understanding the current implementation. This is why you hire the wrong people. And you know it only 1 year down the road. Wrong abstraction. Using framework has its appeal, where a cookie cutter solution mostly work. But it also has its limitation, bloat.
Once a wrong abstraction is in place, the more code/people depends on it, the more effort it takes to refactor