Operatörün Rehberi: Web Uygulaması vs Pazarlama Sitesi

You have a SaaS product and a marketing website. They're currently one Next.js application — the marketing pages, the blog, the pricing page, the login flow, and the entire application dashboard all live in one repo and deploy together.

The marketing team wants to change the homepage headline. The change requires a pull request, a code review, a CI/CD pipeline run, and a full redeployment. The deploy takes 8 minutes. The engineer who has to review the PR is working on a product feature. The headline change ships two days later.

This is the monolith problem. And the standard solution — splitting into separate applications — creates its own set of problems. Here's how to make the decision correctly.

The Monorepo vs Separate Repos Decision

The monorepo approach: marketing site and application share one repository, one framework (Next.js), one design system, and one deployment pipeline. Routes like /, /pricing, /blog/* serve marketing content. Routes like /app/*, /dashboard/* serve the application.

Advantages:

• Shared design system — buttons, typography, and colors are consistent
• One build pipeline to maintain
• Components reuse between marketing and app
• Single domain for SEO authority

Disadvantages:

• Marketing changes require code deployments
• A broken app feature can block marketing deploys
• The marketing team depends on engineering for every change
• Build times increase as both codebases grow
• Test suites run for both app and marketing on every PR

The separate repos approach: marketing site and application are independent projects, possibly different frameworks. Marketing lives at company.com (or www.company.com). The app lives at app.company.com.

Advantages:

• Marketing team can deploy independently
• Failures are isolated — a broken app doesn't take down marketing
• Each team chooses the best tools for their needs
• Smaller, faster builds per project

Disadvantages:

• Design system must be published as a shared package
• Two deployment pipelines to maintain
• Subdomain SEO implications
• Shared authentication requires additional configuration
• Design drift between properties over time

The right answer depends on your team structure. If you have 3-5 engineers working on everything, a monorepo is simpler — the coordination overhead of separate repos exceeds the benefit. If you have a marketing team that needs to ship changes independently and an engineering team focused on the product, separation is worth the infrastructure cost.

SEO Implications of Each Approach

The architectural decision has direct search engine consequences:

Monorepo with subfolder routing (company.com/blog, company.com/pricing) is the SEO-optimal setup. All content shares one domain, one authority pool, and one crawl budget. Blog posts that earn backlinks strengthen the pricing page. The homepage authority lifts every piece of content.

However, the monorepo must serve marketing pages as server-rendered or statically generated HTML. If the entire application is a React SPA (client-side rendered), marketing pages are invisible to search engines until JavaScript executes — and Google's rendering budget is limited and delayed.

Separate app with subdomain (company.com for marketing, app.company.com for the product) means SEO content lives on the main domain with full authority, while the app lives on a subdomain where SEO doesn't matter (authenticated content isn't indexed anyway). This works well for SEO because the marketing domain is clean — no SPA shell, no app-specific JavaScript bloat, no authentication middleware affecting crawl.

The hybrid anti-pattern to avoid: a Next.js monorepo where the marketing pages are server-rendered but share a JavaScript bundle with the application. The homepage loads fast, but its JavaScript bundle includes React components from the dashboard, charting libraries, form validation for the app, and other code that marketing pages never use. The performance cost is significant — we've seen marketing page JS bundles bloated to 400KB+ because of app code leaking through shared imports.

If you use a monorepo, ensure strict code splitting between marketing and app routes. In Next.js, this means separate layout groups, no shared client components between /(marketing) and /(app) route groups, and dynamic imports for any heavy dependencies.

Team Velocity and Ownership

The most important question isn't technical — it's organizational: who owns the marketing site, and how fast do they need to ship?

The content team bottleneck. In a monorepo, every marketing change goes through the engineering workflow: branch → commit → PR → review → merge → deploy. For a content update or a headline change, this is overkill. Content teams need to publish blog posts, update pricing, and launch landing pages without filing tickets.

Solutions within a monorepo:

• Use a headless CMS for content that changes frequently
• Set up Vercel preview deployments so marketing can see changes before merge
• Create a "content-only" CI pipeline that skips app tests
• Give content team direct commit access to /content directories

Solutions with separate repos:

• Marketing team owns their repo and deploy pipeline entirely
• Use Webflow, Astro, or a static site generator the marketing team can manage
• Engineering involvement only for structural changes

The design system challenge. Separate repos mean the button on your marketing page might look different from the button in your app. Design drift is inevitable without active management. The standard solution: publish your design system as an npm package. Both repos depend on @company/design-system. Changes to the system are versioned — marketing can update on their schedule, app on theirs.

The practical middle ground that works for most B2B companies (10-50 employees): monorepo with CMS-driven content. The Next.js application serves both marketing and app. Marketing content comes from a headless CMS that the content team manages directly. Structural changes (new pages, new sections) still require engineering, but content updates (text, images, blog posts) deploy instantly through CMS webhooks and ISR.

The Hybrid Architecture

For teams that need true independence, the recommended architecture:

Marketing site: Next.js or Astro, deployed to Vercel/Netlify, serving company.com. Statically generated. CMS-driven content. Optimized for performance and SEO. Marketing team has full deploy access.

Application: React (Vite), Next.js, or SvelteKit, deployed to app.company.com. Client-side rendered within an auth shell. Optimized for interactivity and feature velocity. Engineering team owns it entirely.

Shared design system: Published npm package (@company/ui) with tokens, components, and styles. Both projects import from the same package. Storybook documents the components. Versioned releases prevent unexpected breaking changes.

Shared domain strategy:

company.com             → Marketing site (Vercel)
company.com/blog/*      → Marketing site (Vercel)
company.com/pricing     → Marketing site (Vercel)
app.company.com         → Application (separate deploy)
api.company.com         → API server

Marketing gets all SEO-critical paths as subfolders on the primary domain. The app lives on a subdomain where SEO doesn't matter.

Shared authentication: The marketing site doesn't need authentication (it's public). The app requires login. The only intersection is the login/signup flow — you can host this at company.com/login (marketing domain, server-rendered for SEO) and redirect to app.company.com after authentication. Share session cookies across subdomains by setting the cookie domain to .company.com.

Analytics: Use one Google Analytics property with cross-domain tracking. GA4 handles subdomain tracking automatically when the cookie domain is set to the parent domain. Search Console needs separate properties for the main domain and each subdomain — or use domain-level verification to capture everything.

FAQ

Should I use a monorepo tool like Turborepo or Nx? If both projects are in the same repository (even with separate deployments), yes. Turborepo (from Vercel) caches build outputs and only rebuilds what changed. Nx provides similar functionality with more configuration options. These tools make monorepo builds fast — marketing changes only rebuild the marketing project, not the app.

What if the marketing team can't manage a static site generator? Give them Webflow or a visual CMS. Webflow produces clean HTML, exports to any hosting, and requires zero developer involvement for content changes. Use Webflow for the marketing site and your engineering-owned framework for the app. The design system bridge becomes Figma (shared design) rather than code (shared npm package).

How do I handle shared navigation between marketing and app? Both sites need consistent top-level navigation. Options: hardcode the nav HTML in both projects (simple, requires manual sync), fetch nav structure from a shared CMS or API endpoint (dynamic, always consistent), or use an edge function that injects the nav HTML into both sites at the CDN level.

Does this architecture work with a mobile app? Yes. The API layer (api.company.com) serves both the web app and the mobile app. The marketing site is web-only. The design system can include React Native components alongside web components if you're building both platforms.

What's the migration path from monorepo to separate repos? Extract marketing pages into a new repository. Set up separate hosting and deployment. Configure path-based routing at the CDN/DNS level to direct marketing paths to the new deployment and app paths to the existing one. Migrate gradually — start with the blog, then landing pages, then the homepage. Keep the monorepo app serving any paths that haven't been migrated yet.