Stack Decisions Are Architecture Decisions
Your tech stack choice isn't about what's trendy—it's about what you'll maintain in production at 2 AM.
I've inherited enough broken PHP applications to know: the stack decision made six months ago will haunt you far longer than the actual feature work.
When I started modernizing legacy systems, I realized most problems weren't technical failures—they were choice failures. Someone picked a tool for the wrong reason, and now you're stuck with it.
Here's what I've learned the hard way:
Pick for maintenance, not velocity. Yeah, you can ship faster with framework X. But if only one person on your team understands it, you've created a bottleneck, not a solution. With Seven CMS and Seven Suite, I chose PHP and NestJS because my team knows them deeply. Speed on day one means nothing if speed on day 180 grinds to a halt.
Consider your ops burden. Docker? Sure, it's powerful. But does your deployment pipeline actually need it, or are you adding complexity because it's shiny? I've seen teams spend two weeks on container orchestration when a simple VPS would've worked. Infrastructure debt is real debt.
Legacy systems teach you this fast. When you're modernizing Odoo or ERPNext installations, you see the cost of previous stack decisions made by people who aren't around anymore. A poorly chosen database structure, a framework that's now unmaintained, vendor lock-in that's actually a prison.
Your open source philosophy matters here. With the Red Hat model—free core, paid support—I need a stack I can support at scale. That means picking boring, stable tools. PostgreSQL over experimental databases. NestJS over the framework of the month. It's less fun but infinitely more reliable.
The framework doesn't matter. The database doesn't matter. What matters: Can you maintain it? Can your team learn it? Will it still be viable in three years?
Make infrastructure decisions, not taste decisions. Your future self will thank you.