First Principles
Removing implementation assumptions to find the fundamental requirement. "We need Redis" → why? → repeated reads are slow. Now evaluate options.
"We need Redis" names a solution. First-principles thinking asks what problem it solves — repeated reads are slow — and only then evaluates options, of which Redis is one. The move is not "avoid tools"; it is "find the requirement before you choose".
"We need Kafka" → why? → async events → why? → checkout should not wait for the email. The real requirement is "send the email asynchronously", and a job table meets it. Kafka may be overkill — and the ladder also says when it is not.
Requirements arrive with implementation baked in: "the cart is stored in the session", "orders are a table", "search hits the database". Strip each implementation word and see what the sentence still requires — often less, sometimes something different.
Payments can fail: that is essential, and every checkout must handle it. Five frameworks for one checkout: that is accidental, and it was chosen. The distinction tells you which complexity to design for and which to remove — and it is not always as clear as the slogan suggests.
"Could work" is the half of the slogan people drop. The simplest thing that could work meets the real requirement — failure handling included — with the fewest parts; the simplest thing that does not is a demo. The move is finding the first, and knowing what evidence would make it insufficient.