IT · 9 min
Choosing a web stack without fashion risk
The best stack is the one your team can still operate next year.
Start with the job. A marketing site, a logged-in product, and a mixed platform are different problems. If you skip this, every later argument about frameworks is theatre.
A content site wants predictable publishing, decent performance, and someone who can change a page without a two-week release. A product app wants authentication, permissions, data integrity and a way to undo mistakes. Mixed platforms need a clear boundary: what is CMS, what is application, who owns the seam.
Hiring reality beats developer excitement. If three people in your city can maintain the stack, and one of them already works for you, that is a stronger argument than a conference talk. Write down who will patch it at 11pm.
Hosting and operations are part of the stack. Where do logs go. Who renews certificates. What happens when a deploy fails on Friday. A beautiful local setup that nobody can restore from backup is not a stack. It is a demo.
Accessibility and security updates are not optional add-ons. They arrive as dependencies, browser changes and legal expectations. Choose tools with a release cadence you can follow. Abandoned libraries are a risk register item, not a personality flaw in the original author.
Document the decision in one page: problem type, chosen tools, rejected tools, and the date you will review. Future you will disagree with present you. The page makes that argument honest.
Shefa scopes web work this way before writing production code. If you want that conversation, bring the one-pager or we will write it with you.