When we tell clients we build marketing sites in TypeScript, the most common response is: isn't that overkill? It's just a brochure site.
It's a fair question. TypeScript adds complexity to a project. For a five-page static site that never changes, that complexity might not pay off. But for a marketing site that will be maintained, extended, and possibly handed off to another team — TypeScript is one of the best investments in the build.
Here's the argument, specifically for marketing sites.
The assumption is that marketing sites are simple, stable, and don't need engineering discipline. This is true at the moment of launch. It stops being true about three months later.
A marketing site after launch gets:
At this point, the "simple brochure site" is running on a non-trivial codebase that's being edited by multiple people, some of whom didn't build the original. TypeScript's value compounds exactly here.
CMS integration is where TypeScript saves the most time on marketing sites. Here's why:
Every headless CMS (Contentful, Sanity, Prismic, Storyblok) returns content as JSON. Without TypeScript, you access this content with no validation:
// JavaScript — no validation
const title = post.fields.title
const author = post.fields.author.name
// What if author is null? What if fields doesn't exist?
// You find out at runtime, on your production site.
With TypeScript, you define the content schema:
interface BlogPost {
title: string
author: { name: string; avatar: string } | null
publishedAt: string
tags: string[]
}
// The compiler tells you about the null case
// before you ship the bug
const authorName = post.author?.name ?? 'Zynra Team'
The benefit isn't academic. CMS schemas change — a field is renamed, a required field becomes optional, a new content type is added. Without TypeScript, these changes silently break your site until a user reports it. With TypeScript, the compiler catches every callsite that needs updating.
We've seen clients with untyped CMS integrations discover content display bugs six weeks after a schema change. The bug had been silently failing that entire time.
Most agencies build a site and hand it off. Whether that's to an in-house developer, a different agency, or a technical co-founder — the handoff is where untyped code creates problems.
TypeScript is documentation that can't go stale. A function signature tells the next developer what it accepts and returns. An interface tells them what shape the data is. An enum tells them what values are valid.
Without types, a new developer reads code and guesses at contracts. With types, the contracts are explicit and compiler-enforced.
The maintenance cost of an untyped codebase compounds over time. Each new developer who touches it adds slightly more uncertainty. Two years after launch, the original developer is gone, the code has been touched by four people, and nobody is confident about what anything does.
JavaScript's failure mode is a runtime error. Something is undefined when the code assumed it wasn't. A function receives the wrong type. An array that should have items is empty.
These bugs reach production. Users see them. They appear in your error monitoring at 2am on a Tuesday.
TypeScript's failure mode is a compile error. The build fails. The broken code never deploys.
For a marketing site, this is particularly valuable because:
A compile error caught during development costs five minutes. A production error caught by a user costs: the user's trust, your team's attention, a hotfix deployment, and the root-cause analysis.
TypeScript isn't universally correct for marketing sites. Cases where JavaScript is appropriate:
You're the only developer and you'll never hand off. The documentation and safety benefits of TypeScript are most valuable across people and time. If this is a solo project you'll maintain forever, the overhead may not be worth it.
The site is genuinely static and genuinely won't change. A true brochure site — five pages, no CMS, no integrations, no blog — built once and left alone — the TypeScript investment doesn't pay off in static HTML.
The timeline is extremely compressed and the team doesn't know TypeScript. Learning TypeScript under a one-week deadline is a recipe for poor TypeScript. In this case, use JavaScript and plan a TypeScript migration.
You're using a framework that handles safety differently. Astro with content collections provides a different form of type safety for content. Svelte's component system has different guarantees than React. The argument is specifically for React/Next.js projects.
We build all client Next.js projects in TypeScript. This includes five-page marketing sites.
Our reasoning: the cost of TypeScript setup is measured in hours. The benefit — safer CMS integration, better handoffs, compile-time error catching — accrues for the lifetime of the project. We've never had a client come back and say "I wish you hadn't used TypeScript." We've had clients come back from JavaScript projects with type-related bugs that cost more to fix than TypeScript would have cost to add.
The "it's just a brochure site" objection usually comes before launch. The people who say it never do so after they've had to maintain one.
Building a marketing site and wondering about the tech choices? Start a conversation — we'll tell you what we'd build for your specific brief and why.
We take on a small number of projects each quarter. Tell us what you're building.
Your site isn't on Google for one of two reasons: it's too new, or it's blocked. Here's how to tell which in two minutes, plus 10 causes and fixes.
LCP, INP, and CLS — what they actually measure, why they matter for search rankings and bounce rates, and the five changes that fix 80% of CWV problems on marketing sites.