Why we needed this
Affiliate sites are a cheap-and-cheerful category of web project. A content site that monetises through commission links: booking partners, tours, accommodation, tickets. There are dozens of profitable examples. There are also hundreds of dead ones, abandoned because the effort-to-revenue ratio didn't clear.
The pattern we saw, across our own experiments and client conversations, was this: the first affiliate site takes weeks to build, and the fifth one takes weeks too, because every site reinvents the same infrastructure. Different themes, but the same jobs underneath - manage listings, integrate booking APIs, build categories, display a map, embed reviews.
One codebase, many sites fixes that. Build the generic platform once, then spin up a new site as a theme and a set of content nodes, not a new solution.
The pattern at a high level
The engine is a single Umbraco 17 solution. It serves multiple hostnames, each with its own content root, its own theme, its own affiliate accounts, its own tax and currency rules. A new site is created by:
Cloning a content template under a new root node
Assigning a hostname (or several) to that root
Swapping in a theme (a CSS variables set plus a few optional Razor partial overrides)
Plugging in that site's affiliate credentials
That's it. A new brand, live on the same infrastructure, in half a day.
Underneath, everything interesting is shared:
Content model: one set of document types (Destination, Activity, Accommodation, Food & Drink, Event, News, etc.) with per-site content sitting under per-site root nodes
Affiliate layer: a set of integrations we wrote once (Booking.com, GetYourGuide, Skyscanner, Amazon, a few more) with per-site credentials and attribution
Search & categorisation: shared search infrastructure, shared tagging, per-site result filtering
Analytics: Plausible, configured per-site
Hosting: one application, one database, one deployment pipeline
What Umbraco 17 does well for this
Umbraco has supported multi-site configurations for years. What makes v17 a better fit than v13 for this specific pattern:
Composed document types compose better. The affiliate engine leans heavily on compositions - a _ListingCore with shared title, summary, rating, price-band, affiliate link fields, then per-type doc types that layer in the specifics. v17's property editor improvements and the polished compositions UI make that pattern genuinely maintainable, not just theoretically maintainable.
The Management API is the production API. We use the Management API (directly and via MCP) to provision new site roots, populate seed content, and sync listing data from affiliate partners. This is much cleaner than the v13 equivalent (which typically meant bespoke services or direct-DB work).
Block Grid and Block List at v17 maturity. Every site page (destination landing, category page, listicle) is assembled from a handful of blocks. Shared blocks, rendered with per-site theming. v13's Block List works; v17 gives us the layout composition we needed without writing a custom editor.
The backoffice scales to more content. We're looking at sites with 500-2000 listings each, spread across several sites. v17's backoffice handles the content tree performance better than v13 under that kind of load.
The theming layer
The part most agencies get wrong in a multi-tenant platform is theming. A theme as "a CSS file" is fine until a designer wants a site with different layout, different heading hierarchy, or different component behaviours. A theme as "a separate Razor project" is overkill and kills the "new site in half a day" promise.
Our theming sits at three levels:
Level 1 - CSS variables. Colour palette, typography, spacing, border-radius. Per-site, overrideable via a single CSS file that loads after the base. 90% of sites only need this level.
Level 2 - Razor partial overrides. If a site needs a different homepage layout, it drops a _Homepage.cshtml into its theme folder and the engine picks it up over the base. About 8% of sites need this.
Level 3 - Per-site services. If a site needs an integration the base doesn't have (a custom events API for a specific market, say), it registers a per-site service that the core affiliate engine resolves from the site's DI scope. Rare. About 2% of sites.
The split means most new brands are Level 1 only, and the engine doesn't get polluted with special cases.
A concrete example: bayr.im
Bayr, our tourism guide to the Isle of Man, was the first public site on the engine. It has:
188 places and attractions (mix of accommodation, food, activities, events)
Real-time weather feed from the Met Office
Tide tables from UKHO Admiralty
News aggregation from ManxRadio and 3FM
Affiliate integrations with Booking.com, GetYourGuide, Direct Ferries, Steam Packet, Amazon, Skiddle
Its own branding (navy/red, Playfair Display serif, compass motif)
Bayr uses Level 1 theming (colours, typography, logo) and Level 2 for the homepage (the island's compass-motif hero is specific to this site). Everything else is the base engine.
When a second site comes online - we're currently scoping entertainthekids.com as the next one - it'll be a Level 1 job. Same engine, same document types, different root node, different theme.
What's on the roadmap
A few things we know need work before we offer the engine to other affiliate operators:
A cleaner theme management UI. Right now a new theme is a folder commit. We want a backoffice admin that lets a non-developer pick a preset and tweak the colour palette without touching files.
Affiliate-source abstraction. We have integrations with seven providers. We want the integration layer to be a plugin model so new providers can be added without re-deploying the whole engine.
Per-site content staging. Right now all sites share a database with per-site content roots. That's fine for our operational model. If we were to let other operators license the engine as a managed platform, we'd need per-site DB separation and per-site deployment cadence.
If this is useful to you
If you run an affiliate network, a tourism business with multiple locations, a group of local directories, or any business where the same content-driven site has to exist in several brand flavours - the affiliate engine is the platform we'd pitch. We can license it, or we can run it as a managed service.
See Platforms on Simplepage.com for the commercial details, or get in touch for a scoping conversation. Bayr is the live-in-the-wild example.