Nobody Cares About Your Tech Stack

Your customer has a billing problem. You have opinions about database drivers. Only one of those things explains why they opened their wallet.

Technical choices matter because they determine how reliably and cheaply you can deliver an outcome. They rarely are the outcome. “Built with the newest framework” is a fascinating detail for someone who was already going to inspect your repository.

Spend complexity where the product is different

Think of complexity as a budget you pay in debugging hours, deployment steps, and mental load. Spend it on a capability users actually need. Keep the surrounding plumbing predictable.

For a small appointment tool, reliable reminders and correct time zones may matter. A custom event bus probably doesn’t. For a medical workflow, security and data handling may be core requirements from day one. “Keep it simple” does not mean ignore the requirements that make the product safe and usable.

Write a short decision note:

• What user requirement does this choice support?
• What is the simplest available option we already understand?
• What concrete limit would make us reconsider?
• Who can operate it when the original developer is unavailable?

That last question is where many beautiful architectures quietly become hostage situations.

Use a walking skeleton, not an architectural cathedral

Build one thin flow all the way through: a real user signs in, saves a real record, another session reads it, and the record survives a restart. Deploy that flow. Check logs, error behavior, and recovery.

A pretty local demo proves very little about the system that must run unattended. Before adding the second major feature, make sure you can:

1. Install dependencies reproducibly.
2. Apply a versioned database migration.
3. Deploy without exposing development ports.
4. Distinguish a healthy process from a working application.
5. Restore a backup in an isolated environment.

These are not enterprise decorations. They are how tomorrow-you avoids apologizing for losing yesterday-user’s work.

Example: the tempting rewrite

Imagine your support inbox has 30 active teams. Pages are slow because a feed query loads every comment for every ticket. Someone proposes rewriting the app in a faster language.

First, measure the request. Count queries, inspect the execution plan, and identify where time is spent. Paginating the feed and adding the appropriate index may solve the problem in an afternoon. A rewrite spends weeks recreating authorization, email delivery, and all the edge cases you forgot were features.

A rewrite may still be right if the existing system blocks necessary behavior. Make that case with evidence: what cannot be done, what it costs, and why incremental fixes are insufficient. Benchmarks from a different workload are not your performance diagnosis.

Delay commitments, not essential safeguards

Avoid premature service boundaries, speculative abstractions, and dependencies whose only job is to make the project look serious. Prefer explicit code you can read over a generic engine configured by 19 files.

Do not delay input validation, access controls, migrations, or backups until “after traction.” Traction makes mistakes more expensive. A single authorized endpoint and a database constraint can be simpler than repairing corrupted records later.

Keep an exit path: exportable data, documented environment variables, and a deployment process another person can follow. Simplicity includes leaving a tool when it stops fitting.

A useful rule for this week

Before changing a tool, name the failure you’re addressing and how you’ll measure improvement. If the answer is “I’ve been meaning to try it,” put it in a side project. That is a fine reason to learn; it is a poor reason to move the customer’s furniture while they’re sitting on it.

Ship the outcome. The stack can enjoy its anonymity.