Usually because the marketing site shares a repository and a pipeline with the product. A copy change now sits behind the same test suite, review queue and release window as a database migration. The technology is fine. The coupling is what hurts.
This decision gets made once, early, usually by an engineer with no marketing work in front of them yet. Two years later it is the reason a headline takes four days to change.
We inherit both arrangements regularly, so we want to lay out the real trade offs rather than the tribal ones. There is a good case for each, and the deciding factor is rarely technical.
One Git repository containing both your product application and your marketing website, usually with shared packages for things like the design system. Tools such as Turborepo, Nx and pnpm workspaces exist to make that arrangement pleasant, and they largely succeed at the build level.
The alternative is two repositories with their own pipelines, deploying independently. Shared code, if you want it, moves between them as a published package rather than a folder import.
Note that this is a separate question from which framework you use, or whether the marketing site is statically generated. You can prerender a marketing site in either arrangement, and you should. Our piece on static versus server rendered sites covers that decision on its own terms.
Shared components that never drift. If your marketing site and your product genuinely use the same buttons, type scale and colour tokens, a monorepo means a change lands in both at once. No version bump, no waiting, no two versions of the same component slowly diverging.
The second argument is atomic change. When a rename touches both codebases, one commit does it and one review covers it. Splitting that across repositories turns a single change into a coordination problem with an ordering requirement.
The third is fewer things to run. One pipeline, one dependency policy, one place to look. For a small team that is a real saving, and we would not dismiss it.
Deploy independence, which in practice means marketing autonomy. A separate marketing repository can deploy in two minutes without running the product test suite, and a broken product build does not block a landing page. That is the difference between a site that ships daily and one that ships fortnightly.
Permissions are the second reason. A marketing site repository can safely include contractors, a content agency, or an AI agent with a narrow remit. Giving those same parties commit access to a repository containing your product is a much larger decision.
The third is blast radius. Marketing sites get experiments, tracking scripts and campaign pages. Product code gets migrations and auth changes. Keeping them apart means an experiment that goes wrong takes down a landing page, not a login.
| Consideration | One repository | Two repositories |
|---|---|---|
| Marketing deploy speed | Tied to product pipeline | Independent, usually minutes |
| Shared design system | Immediate, no versioning | Needs a published package |
| Access for contractors and agents | Broad by default | Scoped to the site |
| Risk of shipping app JavaScript to public pages | Higher | Lower |
| Coordinating a change across both | One commit | Two, in order |
| Pipeline maintenance | One to maintain | Two to maintain |
Mainly through what accidentally gets bundled. When the marketing site imports from the same workspace as the product, it is easy for a component to drag in a date library, a charting package or an analytics client that no public page needs. Nobody notices until the bundle doubles.
That matters because the thresholds are unforgiving. Google's Core Web Vitals guidance sets the good thresholds at 2.5 seconds for Largest Contentful Paint, 200 milliseconds for Interaction to Next Paint, and 0.1 for Cumulative Layout Shift, each measured at the 75th percentile of page loads and segmented across mobile and desktop. Interaction to Next Paint became a stable Core Web Vital in 2024, replacing First Input Delay.
A split repository does not make you fast by itself. It just makes the accident harder. Across the projects we have delivered, the single most common cause of a low PageSpeed score on an inherited site is product code that ended up on a marketing page. Our guide to reducing JavaScript bundle size covers the cleanup.
Context and permissions both get sharper. AI coding agents read instruction files to learn a project's conventions, and the AGENTS.md convention resolves them by proximity: the closest file in the directory tree wins, which is what makes nested files inside a monorepo workable.
That is a genuine point in favour of one repository, and it is new. A root file can carry the rules that apply everywhere, while a file inside the marketing package carries the rules that only apply there. AGENTS.md is used by over 60,000 open source projects and supported by more than 20 tools, and it is stewarded by the Agentic AI Foundation under the Linux Foundation, so the convention is unlikely to move under you.
The counterweight is scope. An agent with access to one repository has access to everything in it. If you want an agent that can edit landing pages but cannot touch billing code, separate repositories give you that guarantee at the boundary rather than by instruction. We would rather enforce that with permissions than with a paragraph in a Markdown file.
Who ships the marketing site, and how often. If engineers own it and it changes monthly, one repository is fine and the shared component argument wins. If marketing owns it and wants to change something twice a week, coupling it to the product release train will make everyone miserable regardless of how good the tooling is.
The second question is whether the design system is genuinely shared. Many teams believe it is when the reality is a marketing site with its own layout language and a product with its own. If the shared surface is really just colours and a font, that is a small package, not a reason to merge repositories.
Be honest about pipeline maturity too. Splitting means maintaining two pipelines, two dependency policies and two sets of preview environments. If nobody owns that, the second repository will rot. Our notes on staging sites and deploy previews cover what that setup needs to include.
For most B2B software companies we work with, a separate marketing repository, with the shared visual language published as a small package rather than imported across a workspace. Marketing autonomy tends to be worth more than atomic commits, because the marketing site changes far more often than the boundary between the two does.
We would choose one repository when the same engineers own both, when the product and marketing surfaces genuinely look identical, or when the team is small enough that a second pipeline is real overhead rather than an abstraction.
What we would not do is switch arrangements to fix a problem that is really about process. If the delay is a slow review culture, splitting the repository just relocates the queue. Fix the queue first and see whether the structural problem is still there.
Time your last five marketing changes from request to live. If most of the elapsed time was waiting for a pipeline or a reviewer who does not care about the change, you have a coupling problem worth solving. If it was waiting for copy approval, you do not, and no repository layout will help.
Then check what your marketing pages actually download compared to your product. That one measurement usually settles the argument faster than a design document. If you want help untangling a marketing site from a product codebase, or working out whether the split is worth it for your team, we are happy to look at it with you at phoenix.studio.
Tell us where you want to go. We'll tell you how we'd get you there.