‘We’ll Add That Later’ Is the Most Expensive Decision

Every website project involves tradeoffs. Things that aren’t critical get cut to keep the budget or the timeline intact. Some of those cuts are fine. A few are expensive in ways nobody warns you about, because the cost shows up later, hidden in the second project that has to retrofit what the first one skipped.

Here’s the short list of “we’ll add that later” decisions that almost always cost more than doing them upfront.

Analytics and tracking

“We’ll set up Google Analytics after launch.” This is the most common defer, and the most expensive. The first three months of a new site are when you learn the most — which pages get traffic, which forms get submitted, which paths visitors take. Miss that data and you’re flying blind through the period when decisions matter most.

A proper analytics setup (Google Analytics 4, a simple events layer, conversion tracking) takes a few hours at the start of a project. Retrofitting it three months later usually takes longer, and you never get back the data you didn’t capture.

Do it upfront. Always. No exceptions. Even a minimum-viable analytics setup beats nothing.

Accessibility

“We’ll fix accessibility when we have time.” Accessibility retrofits are 3-5x more expensive than building accessibly from the start, and sometimes they require fundamental changes — color schemes that don’t meet contrast requirements, components that weren’t built for keyboard navigation, forms that were never structured for screen readers.

The fix isn’t to do the full WCAG audit upfront. It’s to build with the basics in mind: semantic HTML, proper heading structure, labeled forms, accessible color palettes. A developer who does this by default costs the same as one who doesn’t. Hire the one who does.

Content strategy

“We’ll rewrite the copy after we see the design.” This is a trap. Designs built around placeholder copy produce layouts that look great with lorem ipsum and fall apart with real content. Real headlines are longer than you expect. Real product descriptions don’t fit the card you designed. Real testimonials are two sentences instead of three.

Writing the content first, or at least in parallel, produces better designs and better content. It also avoids the awkward post-launch scramble to write copy under deadline pressure, which usually results in whatever was easiest to write instead of what visitors need to read.

Performance budget

“We’ll optimize performance after launch.” A site built without a performance budget accumulates weight like a car with a trunk full of gym bags — each plugin, each script, each image “just this once” adds up. By launch, the site is slow, and fixing it means untangling dozens of decisions, each of which seemed reasonable at the time.

The fix is a hard budget at the start: “the homepage ships under 300KB of JavaScript and loads in under 2 seconds on 4G.” That forces every decision — plugin choices, image sizes, third-party scripts — to justify itself against the budget. It’s an order of magnitude easier than reducing weight after the fact.

Security basics

“We’ll lock it down before launch.” Security work is boring and tends to get pushed. But some security basics — HTTPS, strong admin passwords, limited login attempts, 2FA — cost nothing and should be in place from day one. Adding them after a compromise is how businesses find themselves cleaning up malware at 2am.

SEO foundations

“We’ll work on SEO after launch.” The foundational pieces — proper title tags, meta descriptions, semantic HTML, clean URL structures, a sitemap, schema markup — are cheap and easy during development. Retrofitting them means crawling every page, fixing them one by one, and waiting months for Google to re-index. Ugly.

Most of the SEO basics are also accessibility basics and performance basics. Hitting one usually means hitting all three.

A maintenance plan

“We’ll figure out maintenance after launch.” If this one sounds familiar, you’ve been reading the other posts in this series. A site without a maintenance plan is a site on a timer. Launch day feels like the finish line, then reality sets in. See the separate post on maintenance plans for the full conversation.

What “later” actually means

“Later” in a website project has a consistent definition: “when this is someone else’s problem.” The developer who built it has moved on. The budget is gone. The team has shifted focus. The work that was cheap in the moment becomes expensive precisely because the moment has passed.

This isn’t malice. It’s how projects work. Once a site launches, everyone celebrates, reassigns, and thinks the hard part is over. Coming back to add foundational work weeks or months later is always harder than doing it in the first pass, because the people and the context and the momentum are gone.

The practical rule

At the start of any project, make a list of the “foundational” items — analytics, accessibility, performance budget, security basics, SEO foundations, content strategy, maintenance plan. For each one, ask: do we do this now, or pretend we don’t need it?

The honest answers usually produce a shorter list of deferrals than you started with. That’s fine. You’re saving money, even if it doesn’t look that way today.

Photo by DS stories on Pexels.