Most technical discussions don’t fail because of a lack of knowledge. They fail because the people involved are playing different strategies without realizing it.

One defends “the simple thing that works.” Another demands “something solid and maintainable.” A third wants “to do it right the first time.”

The discussion turns moral, dogmatic, or personal. Words like best practices, overengineering, hack, future, and professional start flying around. And nobody understands each other.

The problem is strategic, not a lack of technical knowledge. You need a mental framework to think before you decide.

There is no universally optimal strategy

In engineering (software, systems, tooling, architecture) there is no solution that always wins. There are trade-offs: risk, cost, reward, reversibility, complexity.

What does exist is a constant tendency to argue as if there were a single correct decision and everything else were mistakes or incompetence.

To name those strategies before discussing tools, I propose a mental framework I call the RPS principle (Rock–Paper–Scissors): it classifies technical or strategic decisions according to what they prioritize and what they sacrifice.

It doesn’t tell you what to choose. It forces you to know what you are choosing.

The RPS principle

The RPS principle starts from a simple idea: every relevant decision falls (explicitly or implicitly) into one of three strategic archetypes.

To refer to these approaches compactly, the framework names them rock, paper, and scissors. As in the game, each shines in certain contexts and proves costly in others.

The labels rock, paper, and scissors are just memorable names; they don’t inherit the rules of the original game or imply fixed relationships between them. They could have been Terran, Protoss, and Zerg, or any other triad.

Below are the three RPS strategies:

Rock: Sufficient pragmatism

Rock is the strategy of “this works and we move on”.

• Minimizes decision time.
• Reduces cognitive cost.
• Solves the immediate problem without trying to optimize everything.

Not elegant, not brilliant, and it works: it prioritizes immediate progress over refinement.

It’s the right strategy when:

• The cost of thinking more is greater than the cost of being slightly wrong.
• The problem isn’t central.
• Reversibility is high.
• Ideal for prototypes and MVPs.

Rock is often criticized for not being “clean” or “correct.” Often, that criticism is pure noise.

Paper: Risk control at a price

Paper prioritizes stability, predictability, and risk control.

• More upfront work.
• More constraints.
• Fewer surprises in the long run.

It’s the strategy of someone who says: “I’d rather pay now than pay later”.

It works well when:

• Failure is expensive.
• The system will live a long time.
• The context is hostile to change.

Paper is often accused of being slow or bureaucratic. Sometimes it is. Sometimes it’s simply realistic.

Scissors: Long-term potential at the cost of risk

Scissors seeks maximum long-term potential.

• More flexibility.
• More performance.
• More complexity.
• More risk.

It’s the strategy of “if we’re going to do it, let’s do it right”.

It can be the best move… or a useless exercise in overengineering if the context doesn’t justify it.

Scissors fails when used out of technical ego or an allergy to simplicity.

A quick example

Imagine you need to persist data for an MVP that will validate whether there’s a market.

• Rock: SQLite or a JSON file on disk. Fast, reversible, enough while you don’t know if the product will take off.
• Paper: Managed PostgreSQL with backups and migrations from day one. Makes sense if you already have paying users or data you can’t afford to lose.
• Scissors: Designing sharding, replicas, and a data model built for millions of rows. Only if scale is already the core problem.

The useful question is which strategy is being used and whether the context justifies it, not which one is more professional.

Where problems come from

Most problems don’t come from choosing badly, but from not knowing which strategy is being used.

Some classic patterns:

• Using scissors when rock was needed (the perfect is the enemy of the good).
• Using paper out of fear, when the real cost of failure was low. (Putting on the bandage before the wound, acting before the problem exists.)
• Criticizing a rock for not being elegant, when it was the right decision for that moment. Think of The Tree Swing cartoon: it serves as a metaphor for situations where a client needs a simple solution and all kinds of misapplied engineering gets built, when what they really needed was a simple, quick solution (even if inelegant) sufficient for that context.

When strategy isn’t discussed, the debate turns religious.

Bridges and Anchors

The RPS principle isn’t complete without two cross-cutting concepts.

Bridges Decisions that reduce the cost of changing strategy later. Typical examples: free software, optional self-hosting, open standards, interoperable formats, containers.

They don’t force you to choose well now. They let you correct course later.

For example: if you choose Supabase to quickly get a backend for your application and at some point the price gets out of hand, you have the option to self-host your own instance on your VPS, with the effort that entails, instead of using the PaaS version. That’s thanks to Supabase having two bridges: it’s free software and can be used both as PaaS and in self-hosted mode. If you choose Firebase instead of Supabase, it’s harder to change strategy, because Firebase anchors you to its platform and makes it costly to move from a third-party backend (Paper) to self-hosting it on a VPS (Rock).

Anchors Decisions that make that change more expensive or block it entirely. Vendor lock-in, closed software, proprietary protocols, rigid dependencies.

They can be convenient in the short term. But they turn reversible decisions into bets.

The difference between a smart decision and a trap is usually here.

What this is for

The RPS principle doesn’t aim to create a new orthodoxy. It does the opposite.

It helps you:

• Think in terms of trade-offs, not dogmas.
• Accept that every strategy wins something and loses something.
• Separate real technical discussions from ideological debates in disguise.

What matters is choosing consciously and preserving optionality when it matters, not always crowning “the best” strategy.

What comes next

Other posts on this blog apply the framework to concrete decisions (as a mental shortcut, not a fixed rule):

• Linux distributions (Debian could represent rock, RHEL paper, and Arch scissors).
• IDEs (VSCode, IntelliJ IDEA, and LazyVim/AstroNvim/NvChad)
• Infrastructure (VPS rock, Cloud paper, Bare metal scissors), already covered in snowflake and IaC, cloud-first, and homelab access.
• Programming languages (Python/TypeScript/Ruby/PHP, Java/C#, and Golang/Rust/Elixir)
• Decisions that come up every day, even when they aren’t named that way.

Not to tell you what to use. But to make clear what you’re paying when you choose.

This post develops the criterion set out in the introduction.