Earlier quoted context omitted.
Practically speaking the data model creates very little value. If your startup is trying to make money, features are more important than design for a good stretch. There comes a time to refactor and fix your architecture but it's usually not at the beginning. You can design a data model if you don't know what you're building. And no startup really knows what they're building.
> Practically speaking the data model creates very little value. That can be said about any cost centre, but you don’t have to drag managers kicking and screaming to get them to buy fire insurance. Practically what it does is allow the company to keep up velocity and not be distracted putting out fires everywhere. Of course building features is the team’s entire reason for existing. But there is no advantage to defer…
They did do some smart things working around such known-unknowns, like operate as a consultancy for several years while building out the tech stack that would ultimately become the product catalog. That way they didn't have enormous risk associated with rewrites since all users were internal and zero projects actually needed feature or ABI with the stack.
The problems they had when I left were obvious, but the data model wasn't one of them. I'll stand by what I said above (ignoring the typo) - you can't specify a data model for a problem you don't know. And no startup really knows what problems they are going to solve when they start.