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.<p>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, <i>BEFORE</i> 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.<p>Once a wrong abstraction is in place, the more code/people depends on it, the more effort it takes to refactor