that's my thought. first customer: build anything they want. second customer: add everything they want, and pay attention to what they don't want. third customer: ok, now we are starting to see a pattern. see if we can satisfy them without any custom features. fourth: ok, this is our product, take it or leave it. new features only if more than half of all customers want it. fifth: by now the first customer may be the odd one out. need to find a strategy to deal with that.
I mean I hate to say this but it's the stuff they teach in CS and PMI: modularity, abstraction, loose coupling, thorough documentation, version control, and design-for-change.
It's 2023 and there's a long ton of off-the-shelf tooling that makes all of this much easier than it was ten years ago.
Modularity and abstraction come up against some limits when different customers have incompatible domain models, and thus different ideas of what your product ought to be.
not in the undergrad courses that i have taken. but that was a few decades ago when computer science covered anything related, and the degrees have diversified since then.
the problem with modularity and abstraction is that in order to make that work you need to step back and be able to build tools and frameworks that are completely independent of customer requirements.
ruby on rails is a successful example of doing that, and other frameworks that came out of some industry need. but a startup who is just getting their first customers doesn't have the resources for that, but also in my opinion are 5 customers not enough to make that move. maybe after 10, or after a few years of working you have accumulated enough experience that you are able to create something like ruby on rails that is modular and abstract enough to really be able to handle every need a potential customer might have.
(basecamp was founded 1999, RoR was released 2004. basecamp as a product came out in 2005. so it took roughly 5 years of consulting work for RoR to emerge)
