Mental Models for Software Decisions

Every day I make dozens of technical decisions. Which framework, which database, which pattern, which tradeoff. Most developers rely on habit or trends. I rely on mental models that produce consistent results regardless of the specific technology.

What Mental Models Are

A mental model is a simplified framework for thinking about a complex problem. Instead of evaluating every option from scratch, you apply a model that filters options quickly. Good mental models save time and produce better decisions.

My Five Core Models

1. The Reversibility Test

Before any decision, ask: 'How hard is this to reverse?'

• Easy to reverse: Choose quickly, optimize later. (Library choice, CSS framework, file structure)
• Hard to reverse: Think carefully, get it right. (Database engine, cloud provider, authentication approach)

Most decisions are more reversible than they feel. The fear of making the wrong choice wastes more time than actually making a suboptimal choice and changing it later.

2. The Boring Technology Principle

Use boring, proven technology for everything except your core differentiator. Postgres over the hot new database. Python over the trendy new language. AWS over the startup cloud.

You get one or two 'innovation tokens' per project. Spend them where they create competitive advantage. Spend everything else on boring technology that works and has good documentation.

3. The Complexity Budget

Every project has a complexity budget. Each technology, abstraction, or pattern you add spends some of that budget:

Simple project:  Python + SQLite + HTML templates
Medium project:  FastAPI + DynamoDB + Next.js
Complex project: Microservices + Kafka + Kubernetes + GraphQL

If your requirements are simple, your stack should be simple. Spending complexity budget on things that do not serve the requirements is waste.

4. The Two-Way Door

Amazon calls this 'Type 1 vs Type 2 decisions.' Type 1 decisions are one-way doors: hard to reverse. Type 2 are two-way doors: easy to walk back through.

Most technical decisions are Type 2. You can switch CSS frameworks, change API patterns, or reorganize code. Treat them as Type 2 and decide quickly.

5. The 80/20 Rule for Features

Build 80% of the value with 20% of the effort. Ship that. Then decide if the remaining 20% of value is worth the remaining 80% of effort. Usually it is not.

Applying Models in Practice

When a client asks 'Should we use Postgres or DynamoDB?', I run through:

1. Reversibility: Hard to switch databases later. Think carefully.
2. Boring technology: Postgres is boring and proven. Good default.
3. Complexity budget: Is DynamoDB's complexity justified by the free tier savings?
4. Two-way door: This is a one-way door. Get it right.
5. 80/20: What queries do we actually need? Does DynamoDB handle them?

The models do not give you the answer. They give you a structured way to think about the question so you make consistent, defensible decisions.

For more on mental models, see Farnam Street's mental models guide.