18+ years of battle-tested wisdom

Technical Philosophy

The principles that guide my decisions — learned the hard way, so you don't have to.

Hint: There's a hidden 7th principle...

0+

Production Incidents Prevented

0+

Hours of Debugging Saved

0

Rewrites Avoided

0+

Happy Clients

The 6 Principles

Click any card to see the war story behind it

Click to flip

Boring Technology

I choose proven, stable technologies over trendy ones. PostgreSQL over the latest NoSQL fad. React over the newest framework.

War Story

The MongoDB Meltdown

Client insisted on MongoDB for a fintech app. 6 months later: no transactions, data inconsistencies, nightmare migrations. We rewrote it in PostgreSQL. Lesson: ACID compliance isn't optional for money.

Saved: 3 months of debugging
Click to flip

Simple Architecture

Start simple, add complexity only when needed. A monolith that works beats microservices that don't.

War Story

Microservices Madness

Startup with 3 developers wanted 12 microservices 'for scale'. Result: more DevOps than features. We consolidated to a modular monolith. Shipped 4x faster.

Saved: 6 months of over-engineering
Click to flip

Performance Budget

Every page under 3s. Every API under 200ms. Performance is measured, not assumed.

War Story

The 8-Second Homepage

E-commerce site loading in 8 seconds. 'It works fine for us!' — on their fiber connection. We cut it to 1.8s. Conversion rate jumped 34%.

Saved: $50K+ in lost sales monthly
Click to flip

Version Everything

Code, infrastructure, documentation — if it can be versioned, it should be. Rollbacks should be trivial.

War Story

Friday Deploy Disaster

Production database schema changed manually. No migration files. Rollback? Impossible. 4 hours of downtime reconstructing from logs. Never again.

Saved: Countless weekend emergencies
Click to flip

Data Integrity

Database constraints, foreign keys, transactions. The database protects your data even when the app has bugs.

War Story

The Orphan Orders

No foreign keys 'for flexibility'. Users deleted, orders remained pointing to nothing. Customer support nightmare. Added constraints, wrote migration to fix 10K orphan records.

Saved: Data trust and sanity
Click to flip

Test What Matters

Not 100% coverage, but critical paths tested. Integration tests > unit tests for business logic.

War Story

100% Coverage, 0% Confidence

Inherited codebase with 100% test coverage. All tests mocked everything. Changed payment logic, tests passed, production broke. Rewrote with real integration tests.

Saved: Real bugs, not fake confidence

What Others Do vs What I Do

Common patterns I actively avoid

Chase every new framework
🏃
Master proven tools deeply
Build for hypothetical scale
🔮
Solve today's real problems
100% test coverage theater
🎭
Test critical paths thoroughly
Microservices from day one
🧩
Modular monolith, split when needed

Why These Principles?

After 18+ years of building systems, I've learned that the best technology choices are often the most boring ones. The latest framework might be exciting, but PostgreSQL has been rock-solid for decades.

Every principle here came from a painful lesson. Every war story is real (names changed to protect the guilty). I share these not to brag, but because these mistakes are preventable.

I'm not dogmatic about specific technologies. The right choice depends on your context, team, and constraints. But I will push back on choices that prioritize novelty over stability.

Want These Principles Applied to Your Project?

Every project is different. Let's talk about the right approach for yours.