Most developers in small teams fall into one or more of the traps of freedom that hurts technically and makes their lives tougher than necessary. With enterpris

Most developers in small teams fall into one or more of the traps of freedom that hurts technically and makes their lives tougher than necessary. With enterprise start-ups you need to be just as agile and fleet-footed as all the b2c start-ups when it comes to backends to survive. Depending upon how much overlap of features across customers your sales pipeline is bringing in, you may share only 10% of code between different customers (basically glorified outsourced software development while pretending to be a product company) and you will need to architect your infrastructure with it too. Getting a feel for where debt exists, fixing it when appropriate, and going at start-up speeds without getting too sloppy is a challenge most b2c developers are familiar with. Hockey stick growth exists as a huge spike as a single customer gets signed, and now you need to scale your software 100x past what you tested within weeks while oftentimes not being able to use modern tools like cloud infrastructure services because your customers forbid it legally. Now add in much tougher (and worse - specific) infrastructure and security requirements across the board and it's no wonder b2b software tends to suck. Hiring developers early on with prior experience in the business domain is critical for company success for this reason. Every developer knows how developers work, so tools by developers for developers tend to work fairly often. Most developers probably don't know anything about how your customers work though and will have difficulty prioritizing what's the most fluid parts and what's not regardless of how brilliant and fast they may be. It's tough to tell whether haphazard selling or haphazard technical design has a bigger impact upon codebases. Add in realities like team turnover and even technical design may matter little compared to how well a codebase is documented for the health of the codebase. I can stare at thousands of unit tests but without some history and organizational know-how it's likely for a successor to repeat the same mistakes by trying to mimic existing patterns.