The code that you can't afford to rewrite is the code that is hairy with details. The details are some mix of essential and incidental complexity. The ratio is

The code that you can't afford to rewrite is the code that is hairy with details. The details are some mix of essential and incidental complexity. The ratio is dependent on the degree of fit between your business logic and the framework, the primitives it's built out of, whether it's third-party, custom framework, custom language, whatever. And of course any custom component has its own complexity; it should be additive, but it may still be large. A good fit - an excellent fit - means your business logic is clear, concise, and is operating over abstractions that map directly to the business concepts. A poor fit is speaking haltingly in unidiomatic language, too verbose, aggregating globs of ugly code, losing track of the forest for the trees, etc. But it'll be easier to find average devs who are familiar with the particular style of thicket that ends up coming out. We even have names for the scar tissues that grow around each glob, helping them interface - we call them design patterns. There's no hard and fast rules, it seems to me. Use a small fraction of lots of different third party bits and pieces and you get a recipe for pain. I'm fairly certain there's no more productive way for engineers to code than to raise the level of their language into their business domain - http://www.paulgraham.com/progbot.html http://www.paulgraham.com/progbot.html - but this is the custom framework / language approach. I'm also fairly sure that it's hard to scale an organization around this approach because of the incentive problem when hiring developers. I think it only really works for startups that are composed of a bunch of hackers with decent equity stakes. It doesn't work out for employees, unless the company ends up moving the needle industry wide, like Java or Rust or React, and that's really rare, too rare to bet on.