Tech stack decisions usually get made by whoever’s building the site — which makes sense, since they’re the ones who have to build it. The problem is that a stack chosen purely for developer convenience can quietly become a bottleneck for the team that has to run campaigns on top of it.

A few things worth weighing before committing to a platform:

Can marketing edit a landing page without a deploy? If every headline change requires a developer and a release cycle, campaigns will always move slower than the market does. A CMS or page-builder layer that lets non-developers make content changes safely is worth the setup cost.

Does the analytics and tracking setup survive a redesign? Sites get rebuilt. If your conversion tracking, pixels, and historical data aren’t portable, every redesign becomes a measurement blackout for weeks.

How easily does it integrate with the tools marketing already depends on? Email platforms, CRMs, ad platforms — if connecting them requires custom development every time, that’s a recurring cost that never shows up in the original project budget.

Who’s maintaining it in a year? The trendiest framework is a liability if it needs specialized expertise to patch and nobody on the team — internal or agency — actually has it.

None of this means marketing should dictate technical architecture. It means the two decisions shouldn’t be made in isolation. The stack that’s easiest to build isn’t always the one that’s easiest to run a business on top of — and that gap is usually invisible until six months in, when someone’s waiting on a dev ticket to fix a typo.