Run the web platform as a product, not a project

A marketing or web platform outlives the project that ships it. Treating it as a product changes which decisions you take seriously.

Evaluate on what predicts the next five years. When choosing or replacing a stack, anchor on a few criteria that actually matter over the platform lifetime: vendor support, the editorial experience for the people who publish every day, and performance. Run real proofs of concept against several options rather than selecting on reputation.

Migrate as a parallel cutover, not a big bang. Define the minimum viable platform, move the highest-value sections first, and keep the old system serving everything else until each piece is genuinely ready.

Own architectural standards before handing work to an outside partner. An external team optimizes for its own delivery date, not for whoever maintains the platform afterward. Component standards and ownership of the platform layer have to be non-negotiable up front. Cleaning up an over-engineered handoff later is far more expensive than enforcing the standard during the build.

Favor configurable, reusable components over single-purpose sprawl. The cost of a rigid component library is paid every day by the people who publish on it. Consolidate toward components driven by configuration rather than a new variant for every use case.

Treat third-party scripts as platform surface. Wrap them, load them on consent, isolate their failures, and measure their real cost to page load. Batch-injecting vendor tags and hoping for the best is how a platform quietly gets slow.