how to evaluate the engineering cost of a marketing site in your product repository
Keeping your marketing site inside the core product repository creates sprint friction and release coupling. Use this framework to evaluate decoupling.
At seed stage, housing the marketing website inside the primary product repository is standard practice. A single repository, one deployment pipeline, and shared UI components let a small founding team launch quickly.
As the engineering organization grows, that shared repository often introduces operational friction. Marketing requests compete with product roadmap priorities, and routine copy or pricing updates require full application build pipelines and engineer reviews. Evaluating whether to decouple requires assessing actual developer time, release risk, and the operational overhead of maintaining a separate frontend.
how much does it cost to maintain a marketing site with core engineers?
The financial cost of managing a marketing site internally is primarily the opportunity cost of diverted engineering capacity:
$$\text{annual capacity cost} = \text{total annual loaded payroll} \times \text{share of sprint time spent on marketing tasks}$$
For example, consider an engineering pod with the following profile:
| Team parameter | Illustrative value |
|---|---|
| Full-stack engineers supporting marketing tickets | 6 |
| Average fully loaded compensation per engineer | €140,000 / year |
| Total annual engineering payroll | €840,000 |
| Estimated sprint time spent on marketing updates | 15% |
| Annual capacity allocated to marketing updates | €126,000 |
This figure does not represent direct cash savings that can be recovered by purchasing a tool or refactoring code. The engineers remain on payroll. The cost is the roadmap work they cannot complete: core feature delivery, infrastructure scaling, technical debt remediation, and customer-reported bug fixes.
The 15% sprint time in this model is an illustrative example. To find your team’s real figure, audit Jira or Linear tickets over the past 6 to 8 weeks and categorize requests by destination.
what tasks create friction when marketing shares a product codebase?
When marketing pages live alongside core application code, routine editorial changes encounter full software development lifecycle controls:
- Sprint backlog contention: Simple updates—such as changing a pricing tier, adding customer logos, or creating a landing page variant—enter the same sprint queue as backend API work and security patches.
- CI/CD build delays and deploy risk: Deploying a copy update triggers the full application continuous integration suite, unit tests, and integration pipelines. If an unrelated backend test fails, the marketing update is delayed. Conversely, a typo fix deployed to production carries unnecessary deployment risk for the core app.
- Framework hydration overhead: Full-stack frameworks like Next.js or Remix are optimized for complex client-side state and authenticated user interactions. For content pages, loading and hydrating an application runtime adds unnecessary client JavaScript, increasing mobile Largest Contentful Paint (LCP) and Interaction to Next Paint (INP) without user benefit.
- Editor dependency on developers: Non-technical marketing and growth teams cannot update page copy or publish case studies independently. Every change requires an engineer to write JSX, open a pull request, and wait for code review.
when does keeping the marketing site in the product repository make sense?
Decoupling is not always the right choice. Keeping the marketing site unified with the core product codebase is appropriate when:
- The team has fewer than 5 engineers: At early stages, managing two separate repositories, two deployment setups, and two domain routing configurations adds more administrative overhead than it saves.
- Pages require deeply shared product state: If the landing pages display live application data, real-time authenticated dashboards, or complex shared session logic, decoupling can require building and securing custom public API endpoints.
- The company lacks dedicated marketing staff: If software engineers write and publish all marketing copy themselves, introducing a headless CMS adds configuration without creating editorial independence.
what are the trade-offs and costs of decoupling?
Moving the marketing site to a dedicated frontend stack introduces new operational responsibilities that must be weighed against sprint savings:
| Area | Monorepo / Shared Application | Decoupled Architecture | Trade-off to Consider |
|---|---|---|---|
| Deployment pipeline | Single CI/CD pipeline | Independent edge deploy | Requires separate domain and proxy routing |
| Content updates | Pull requests via Git | Headless visual CMS (e.g., Storyblok) | CMS subscription costs and team onboarding |
| Design consistency | Shared UI component package | Synchronized tokens or separate library | Potential drift between marketing and app styling |
| Runtime performance | Full framework client hydration | Static HTML with isolated islands (0 KB JS) | Eliminates runtime overhead on content pages |
| Team ownership | Engineering owns all updates | Marketing publishes independently | Engineering must maintain component schemas |
how to evaluate whether decoupling is worth the effort
Before undertaking an architectural migration, follow this evaluation sequence:
- Track sprint allocation for two full sprints: Have the engineering team tag all marketing, landing page, and tracking pixel tickets. Calculate the exact hours spent on content and marketing maintenance.
- Audit release frequency and deployment bottlenecks: Measure how often marketing requests are delayed by engineering sprint schedules, and how often marketing deploys disrupt the release queue.
- Run a low-risk proof-of-concept: Extract a high-traffic sub-route (such as a blog or documentation section) onto a static edge platform before planning a full migration.
We built Apex as a reference architecture modeled on a developer platform to test decoupling editorial routes into Astro and Storyblok. In our lab benchmarks on throttled 4G, pre-rendering static routes cut mobile LCP to 0.62 seconds while removing client JavaScript runtimes from content pages. Apex is an engineering reference build designed to demonstrate frontend architecture; it does not represent client data or a guaranteed conversion outcome.
Decoupling is justified when the developer hours spent on routine content updates exceed the maintenance overhead of managing a separate content platform.
