The Stack Decision
Every niche site network eventually faces a stack decision. WordPress vs. static site generators vs. headless CMS vs. custom builds. The choice affects everything that follows.
We tried most of them. After three years of iteration, we standardized every site on a Nuxt-based stack with shared layers. The decision saved us hundreds of hours and let us focus on content and monetization instead of infrastructure.
Here's what we tried, what we learned, and why Nuxt layers won.
The Stacks We Tried
WordPress + Plugins
The good: Huge ecosystem, easy content editing, every feature you can imagine has a plugin, hosting is universal.
The bad: Performance requires constant optimization. Security is a real concern at scale. Plugin conflicts create operational overhead. Updates break things.
The verdict: Works for individual sites. Doesn't scale to a network. Operational overhead grows linearly with site count.
Webflow
The good: Visual design, no code required for content editors, clean output.
The bad: Expensive at scale. Limited for content-heavy sites. Limited customization for complex functionality.
The verdict: Great for landing pages. Wrong fit for content-heavy niche sites.
Next.js (Custom Builds)
The good: Full control, excellent performance, strong ecosystem, great DX.
The bad: Every site becomes a unique project. No reuse across sites. Maintenance burden scales linearly.
The verdict: Powerful but expensive to maintain. We built sites this way and learned the limits quickly.
Static Site Generators (Astro, Hugo, Eleventy)
The good: Excellent performance, simple deployment, low hosting cost.
The bad: Limited dynamic features. Adding comments, search, or user accounts requires custom work. Most SSGs don't have the ecosystem Nuxt does.
The verdict: Good for purely content sites. Insufficient when you need any dynamic features.
Nuxt (Custom Per Site)
The good: Full Vue ecosystem, file-based routing, content module, good performance, excellent DX.
The bad: Without shared structure, every site is its own project. Maintenance still scales with site count.
The verdict: Close to right. Missing the reusability layer.
The Pivot to Nuxt Layers
Nuxt 3 (and now 4) introduced layers — a way to share code, components, configurations, and content collections across multiple Nuxt sites.
Layers changed everything for us. Instead of building each site from scratch, we built a small number of shared layers:
- Base layer: Core layouts, components, utility functions, design system
- Content layer: Article schema, SEO components, content collections, related-content logic
- Affiliate layer: Disclosure components, affiliate link handling, monetization patterns
- Brand layer: Site-specific theming, voice configuration, brand assets
Each consuming site extends the layers it needs and adds site-specific configuration. The result: a new site takes days to stand up instead of weeks.
What the Layers Contain
Base Layer
The foundation. Every site gets:
- Layouts: Header, footer, navigation patterns
- UI components: Buttons, cards, modals, accordions
- Design tokens: Colors, typography, spacing
- Utility functions: Formatters, validators, helpers
- Standard pages: About, contact, privacy policy templates
The base layer has no opinions about content or monetization. It's pure presentation.
Content Layer
For content-heavy sites:
- Article collection schema (validated frontmatter)
- Blog index pages
- Related articles logic
- Reading time calculations
- Table of contents generation
- Schema.org structured data
- Open Graph and Twitter card handling
- Sitemap generation
The content layer ensures every article has consistent SEO, schema, and metadata without manual work.
Affiliate Layer
For monetization:
- Affiliate disclosure components
- Product comparison table components
- CTA components with proper disclosure
- Affiliate network link wrappers
- Conversion tracking utilities
The affiliate layer enforces compliance across every site. We can't publish an article without the disclosure because the components require it.
Brand Layer
Site-specific identity:
- Logo and asset handling
- Color palette
- Typography choices
- Voice and tone configuration
- Site-specific content collections
The brand layer is where sites differentiate. Everything else is shared.
The Architecture in Practice
A typical site in our network has this structure:
my-niche-site/
├── nuxt.config.ts (extends layers)
├── app/
│ ├── pages/ (site-specific pages)
│ ├── components/ (site-specific components)
│ └── content/ (site-specific content)
├── public/ (site-specific assets)
└── package.json
The nuxt.config.ts extends the layers:
export default defineNuxtConfig({
extends: [
'@xenterprises/nuxt-base',
'@xenterprises/nuxt-content',
'@xenterprises/nuxt-affiliate',
],
// site-specific overrides
})
Everything else — components, layouts, utility functions — comes from the layers. The site-specific code only contains what's unique to this site.
What We Gained
Faster Site Launches
A new site takes 3-5 days to stand up versus 3-6 weeks with a from-scratch build. Most of that time is content production, not infrastructure.
Consistent Quality
Every site has the same SEO setup, the same disclosure compliance, the same design system. Quality is consistent because it's enforced by the layers.
Easier Maintenance
When we update the content layer to add a new SEO feature, every site gets the update. We maintain infrastructure once.
Lower Operational Cost
The shared layers mean smaller codebase per site. Less code means fewer bugs, faster audits, easier team training.
Better Onboarding
New team members learn the layers once. Every site they work on afterward uses the same patterns.
What We Sacrificed
Less Per-Site Flexibility
The layers enforce patterns. Sites that need fundamentally different structures can't use them. We've turned down sites because they didn't fit.
Layer Maintenance Burden
The layers themselves need maintenance. Updates to Nuxt require layer updates. Each new feature must be implemented in the layers.
Versioning Complexity
Sites use specific layer versions. When we update a layer, sites don't automatically update. We manage versions explicitly to avoid breaking sites.
Less Innovation Freedom
It's tempting to try a new framework or pattern on one site. With standardized layers, that requires building the layer first. We've said no to some experiments.
What We'd Build Differently
Document Layer APIs Better
The boundaries between layers weren't always clear in early versions. We refactored multiple times to get clean separation.
Build More Test Coverage
Layers affect many sites. A bug in a layer affects many sites. Test coverage is essential. We added it incrementally but wish we'd started with comprehensive tests.
Establish Layer Versioning Earlier
Sites got out of sync with layer versions before we formalized the process. Adding explicit versioning and update procedures prevented cascading problems.
Plan for Multi-Brand Layers
Each site has a brand layer. As we scaled, brand layer consistency became harder. A design system layer that brand layers extend would have been cleaner.
The Decision Framework
For other operators considering standardization:
Standardize When
- You operate more than 3-5 sites
- The sites share enough structure that standardization helps
- You have the team or skill to maintain shared infrastructure
- The benefits of consistency outweigh the loss of per-site flexibility
Don't Standardize When
- Each site has fundamentally different needs
- The team lacks capacity to maintain shared infrastructure
- The sites are at very different stages or scales
- You're still figuring out your process
Start Standardization When
- You find yourself rebuilding the same component for multiple sites
- You have at least 3 sites in active operation
- The team is comfortable with the underlying framework
- You can invest 1-2 months in the layer architecture
The Bigger Lesson
Standardization isn't glamorous. Building layer architecture instead of features feels like overhead. But over years of operation, it's the difference between a portfolio that's manageable and one that's overwhelming.
The sites in our network that thrive all run on the same layers. The components we built once serve dozens of sites. The patterns we refined once apply everywhere.
The investment paid back many times over. The decision to standardize is one we'd make again — earlier if we could.
