> 6. Hire only fullstack devs. There is nothing less productive in this world than a team of developers. Huh? And those "fullstack devs" will do everything alo

> 6. Hire only fullstack devs. There is nothing less productive in this world than a team of developers. Huh? And those "fullstack devs" will do everything alone or what? Maybe if you are building a proof-of-concept prototype with a useful half-life of 6 months before you sell the company to someone else (and let them deal with the mess under the carpet) but not once you actually start selling the product - and mainly, have to maintain it. I have spent 11 years in such startup - and this "fullstack" mentality, with everyone being "expert" in everything led to quick and dirty solutions that worked for getting a release out to the client - and repeatedly kept blowing up in our faces every few months afterwards. "Fullstack developer" is myth. Yes, people can learn a little bit of everything to get a cobbled up solution out of the door. But this doesn't scale and will severely impact the quality of what you are delivering over time. At some point you will need to invest in specialists or let people specialize, especially if you are building anything beyond some trivial web apps. Ignore at your own peril ... >18. Scrum is a Scam. If I had a team that had to be nagged every morning with questions as if they were children in kindergarten, then things would eventually fail. The only good stuff I managed to do happened with people who were grownups and could manage their stuff. We would just do everything over chat as a sync on goals and plans. No offense, but that only means you don't understand Scrum and are cargo-culting it instead. Which is, unfortunately, common. People focus on the process minutiae and lose sight/don't understand why that process exists and what it wants to achieve. Then they declare that "Scrum is a scam" instead of adapting it to their needs, while keeping the spirit/idea behind it (i.e. not turning it into a waterfall/whatever). There is nothing in Scrum that explicitly prescribes that one must have an in-person standup every morning - and that the same cannot be done over chat or some other means. The point of these things is to have a daily sync point for all stakeholders. And that explicitly includes the usually very busy founders/partners if they are part of the development team (e.g. as product owner(s) ). This is vital for the developers if they are to build what the business/customer actually wants because the PO needs to be there to answer questions - and also for the PO/business stakeholders to have an overview how things are going and what needs to be organized/fixed/resolved for the team to keep moving forward towards the objective. Specifically, this is not intended for you to organize or manage the time of your team! You are there to only to set the goals (at the sprint planning usually) and to clear the way for the team as required e.g. by providing necessary resources which may come up during the sprint. If you can make do without such formal structure only with chat - by all means do so. However, it does not scale and you will discover this rather quickly as your team(s) grow in size and scope - even with 3 people it is often too much already. Unless your team is capable of reading minds you will sooner or later end up inundated with organizational questions over the day, which is both distracting and slows everyone down - the busy founder/owner/PO becomes a bottleneck. We had this in the startup I was in. The owner was practically impossible to get hold of because he was constantly busy, important decisions only he could make were thus not being made, projects were being delayed because of this, etc. At my current company we have Scrum implemented in the more-or-less original form, with 15 minutes long standups over Microsoft Teams (we are mostly remote) every morning so that everyone knows where we stand, what issues need to be solved and what are we going to be doing today. Some teams have a longer technical follow-up afterwards for the developers (the PO and scrum master usually leave at that point) if required, others don't. However the meeting is an important point to get the daily "bureaucracy" out of the way so that the organizational distractions can be kept to the minimum during the day.