When MVPs Grow Teeth

"Bad models are rarely designed by teams on purpose. Most of the time it's the model you get by being pragmatic: shipping an MVP, and then doing the next reasonable thing... repeatedly... for two years. You start with a product structure that fits a world where you can store something on a shelf, put it in a box, and ship it to a customer."

"The first few steps are innocent. You add fields. You add a boolean or two. You add an enum. You add an interface because you don't want a giant `if` statement. It reads well in code review because it mirrors English: a customizable product is a product; a shippable product can be shipped. But you may be unintentionally building a trap."

"The trap is that these abstractions don't emerge from a grand design. They arrive release by release, each one locally reasonable, but over time they add up to a web of derived classes and interfaces and a crash course in GoF patterns. Half the products are shippable but only some are returnable, and 'returnable' depends on whether it is customized."

Product models evolve through pragmatic, incremental decisions as businesses grow and adapt. Initial structures accommodate basic products, then expand with attributes, customization options, subscriptions, and digital entitlements. Each step seems locally reasonable—adding fields, booleans, enums, and interfaces to handle new requirements. These abstractions appear elegant in code reviews because they mirror business language. However, this approach creates a trap: abstractions emerge release-by-release without grand design, accumulating into complex webs of derived classes and interfaces. Business logic becomes tangled across multiple conditions—products may be shippable but not returnable, with exceptions for subscriptions, digital licenses, and bundles. This complexity eventually manifests as pain in critical business operations.

Read at Medium