Inspired by Nir Eyal's "beliefs are tools" framework
Beliefs are tools, not truths. Tech stacks are too. Pick the ones that work for you.
Most "tech debt" is actually "belief debt". We hold onto frameworks, patterns, and processes long after they stop serving the product. To build great software, we need to introduce a core rule: If a tech belief or "best practice" doesn’t solve a real problem for you right now, it must be treated as false.
Here is how to audit your tech beliefs using 5 filters.
1. ARE THEY USEFUL?
The real question isn’t "Is this the best tech?" It’s "Does this serve the user?"
Tools are tools. Keep the ones that ship.
- Bad belief (Treat as False): "We need Kubernetes because it’s the industry standard."
- Useful belief (True for Now): "A $5 VPS serves 10k users. We’ll use K8s when we have a scaling problem, not a resume problem."
If your architecture choice doesn’t make the core loop faster, cheaper, or simpler for users, it’s not serving you. Delete it.
2. ARE THEY TESTED?
A useful stack holds up when the world pushes back. Pay attention to production, not the trending blog posts.
- Bad belief (Treat as False): "Microservices are inherently more scalable"—said before you even have 2 concurrent users.
- Tested belief (True for Now): "Our monolith handles 50 req/s perfectly. We’ll split services only when latency exceeds 300ms in prod."
Load test it. Dogfood it. If it only works in a conference slide deck, it’s a story, not a tool.
3. ARE THEY OPEN?
A tech choice you can’t change has stopped being a tool and has become a cage. Hold opinions firmly, but hold implementations loosely.
- Bad belief (Treat as False): "We’re a React shop forever."
- Open belief (True for Now): "React serves us today. If HTMX lets us ship this feature in 2 days instead of 2 weeks, we’ll use HTMX."
In a famous study on hope, Curt Richter’s rats swam for 60 hours when they believed rescue was coming. Your team will grind for years on a legacy stack if they believe it can actually be refactored. Lock-in kills hope. Escape hatches keep teams swimming.
4. ARE THEY HONEST?
If keeping the stack means looking away from your core metrics, it’s costing you money and sanity.
- Bad belief (Treat as False): "Our GraphQL layer is incredibly flexible" (while your TTFB is 2.1s and junior developers can’t query it).
- Honest belief (True for Now): "GraphQL is slowing us down. A basic CRUD API will let us ship tomorrow."
Drop stacks that require you to lie to yourself during retrospectives. If you’re constantly explaining away bugs, customer churn, or onboarding delays, the belief itself is the bug.
5. ARE THEY LIBERATING?
Some architectures open doors. Others quietly close them. Keep the ones that give your team agency.
- Bad belief (Treat as False): "We can’t launch until the event-driven saga pattern is architected perfectly."
- Liberating belief (True for Now): "A cron job and Postgres gets us 80% of the way there. We’ll ship today and refactor when scale demands it."
A Columbia University study showed a 75% drop in depression symptoms for people who felt a sense of personal agency. Teams with agency ship code. Teams trapped by dogmatic "best practices" drown in meetings.
WHAT TECH BELIEFS CAN DO
| Impact metric | The Reality behind the Metric |
|---|---|
| 60 Hours | How long a team will debug a flaky E2E test suite if they blindly believe "100% coverage" will save them. (Teams with simple tests but high trust can ship a fix in 15 minutes). |
| 7.5 Years | How much longer codebases last when built with simple, boring tech. It is a far bigger predictor of software longevity than rewriting in Rust or Elixir. |
| 75% | The drop in support tickets and feature requests when you delete bloated settings pages. For most products, configuration is a tax on users who just want the defaults to work. |
UPGRADE YOUR TECH BELIEFS
| Dimension | Old Belief (Treat as False) | New Belief (Useful Tool) |
|---|---|---|
| Action | "We need a fully approved RFC before we write a single line of code." | "We can ship a spike in 2 days and learn from production telemetry." |
| Difficulty | "If it’s hard to build, our architecture must be wrong." | "If it’s hard, we are simply tackling real-world, inherent complexity." |
| Failure | "We tried NoSQL once before and it failed to scale." | "Our previous attempt taught us where our actual system constraints lie." |
| Identity | "We are strictly a TypeScript company." | "We use types when they prevent critical bugs and speed up developer velocity." |
| Ability | "I’m just not a DevOps person." | "I haven’t found the medium where Infrastructure-as-Code clicks for me yet." |
The Point
A program is just what we agreed should be done, then automated. Your stack is just a belief about how to do it.
- Excel is SQL.
-
localhostis production if it automates your house. - A Google Sheet that texts your users is real software.
Beliefs that serve you look like: shipping fast, using simple CRUD APIs, and deleting dead code.
Beliefs that do not serve you look like: arguing over aesthetics, waiting for perfect alignment, and calling simple solutions "amateur."
Hold your users firmly. Hold your tech loosely.
Agreement is the only real tech stack.
Top comments (0)