Software is a collection of decisions, some explicit, some implicit.

The most expensive decisions - microservices, event-driven architecture, immutable data, for some examples - are essentially CAP tradeoffs, almost always buying availability with consistency. Availability in the general sense, which often is a proxy for extensibility, which itself is a technical term meaning you can pivot this business into additional verticals / multiple produces / two-sided marketplaces.

By expensive, I don't mean $$. I mean more like these are the things that will determine if you can build at 1x, 2x or 10x pace.

The tradeoff goes in that direction - consistency for availability - because the simplest form of web software is highly consistent and minimally available. Of course: since there's only one consumer, there's only one source of truth, and that source only needs to be available to that one consumer.

A lot of those decisions are made for political, resume-driven, or just plain boredom - that's another post though.

The above-board for these decisions are like this: we want additional availability for the product catalog so we can replicate globally, accept writes in multiple regions, let new surfaces/features read from caches without blocking on the primary DB. Etc.

The hidden cost of these tradeoffs? Complexity. Trading consistency for availability almost always incurs complexity.

Complexity is what makes a simple feature take months to ship, and what makes otherwise straightforward sounding new products take quarters to launch.

A curious thing I've noticed about software engineering at startups: Except in rare cases (Google and its products comes to mind) it seems to be less of a positive differentiator than a thing that is either neutral for growth if done well, or an anchor if done poorly.