Organisations with many units end up with many websites: a main site, a site for each programme, project or office, an intranet, a portal for members. Built one at a time, they drift apart in design, in security updates and in how editors work, and each one costs as much to change as the first. We build them as a family on a shared Drupal base: one design system, one place where updates are made and tested, and a site for each unit that its own editors run.
The SPREP family of sites Which sites we developed from sprep.org, and which we built on their own
Who this is for
- A regional or intergovernmental organisation. A main site, plus sites for programmes, services and networks that each speak to their own audience.
- A ministry, council or university with units. Departments, faculties or offices that need a site of their own inside one identity.
- A franchise or a group with branches. A storefront for each location on one platform, with a central view across all of them.
- An organisation with scattered sites already. Drupal sites built at different times by different teams, to be brought onto one base in stages.
- An agency with a client that runs several brands. A family of sites delivered under your name through white-label development.
What you get
- A written line between what every site shares and what each site decides
- A shared design system and component library, with the room each site has written down
- A reference site built first, which every later site is measured against
- An architecture chosen for your case: Drupal multisite, a shared distribution, or one site with many front doors
- A template for adding a site, so each new one is priced and launched the same way
- An update path that takes a security release to every site, tested on the reference site first
Sample Shared and local Agreed before the first site is built
Shared by every site
- Design system and component library
- Content types for news, events and documents
- Security releases and module updates Tested on the reference site first
Decided by each site
- Its own content, menus and home page
- Its own editors and approvers
- Its own address and logo lockup Within the brand rules
Decided centrally, on request
- A new component for the shared library
- A new content type or vocabulary
- A new language
An engineer reads it and replies within one business day.
How the work runs
The order is the same as for any build we run, with the platform built once and sites added in waves. The process is written up in full in how a project with us runs.
How a family of sites is built
- Discovery Across the units: what must be shared, and what each may decide. Output: the shared-and-local agreement
- Prototype A reference site on the shared design system, at no charge. Output: the prototype
- Fixed price The platform priced first, then each wave of sites against the template. You keep the architecture document
- Build Platform and design system built once, then sites added in waves. You keep the repository
- Acceptance The platform accepted centrally, each site against the same checklist. You keep the test record
- Warranty Defects in what we built are ours to fix, one year by default and up to three. You keep the handover pack
Multisite, a distribution, or one site with many front doors
"Multisite" is used loosely for architectures that share the aim of one base for many sites and differ in what is actually shared. The choice follows from the line between shared and local, not the other way round, and it is made in discovery.
| What differs | Multisite | Distribution | One site |
|---|---|---|---|
| Code | One codebase serves every site | Each site runs its own copy of a shared base or installation profile | One application |
| Database | One per site | One per site | One, shared by every unit |
| Updates | Once, reaching every site at the same moment | Released to each site on its own timing | Once |
| How far a site can differ | Configuration and theme per site; the code is common | A site can add modules of its own | Within what the application allows each unit |
| Suits | Units that must stay in step | Units with different needs that share a starting point | Branches run to one pattern, such as the stores of a franchise |
MenuNerds, our restaurant platform, works as one site with many front doors. In the Australian franchise that runs it, each store has its own subdomain, and a store added later joins the same platform through the franchise admin's multi-store setup rather than as a separate site. For units that publish independently, with editors of their own, multisite or a shared distribution is the usual candidate.
A family of sites in practice
SPREP's sites show what a family looks like from the outside. After we redesigned sprep.org, SPREP gave us further sites, and PRISMSS and the Pacific NbS Resource Hub were developed from the sprep.org base, as was Fagogo, the staff intranet. They carry the SPREP identity, and PRISMSS uses the same news categories as sprep.org. Each still has its own sections, audience and editors: PRISMSS runs in English and French with a profile for each participating country, and the Hub is a resource library with member accounts.
Not every related site belongs in the family. The SPREP Virtual Library and the Pacific Islands Roundtable site were built as sites of their own. Which sites share a base, and which stand apart, is decided in the first step rather than discovered later.
What it costs
A platform for many units is the Multi-Entity tier on the pricing page. The platform is contracted first, then each wave of sites against the per-site template, so the cost of adding a unit is known before it is added.
A smaller family, such as a main site with a few related sites built from its base, can fit a lower tier, and discovery tells you which. Maintenance covers the platform and each site, and is priced separately under maintenance and support.
Terms that hold
These terms hold across our services; where a service starts differently, its page says how. The full wording is on the warranty page and in why you own the source code.
- A prototype before you sign a build Before a build project is signed, we build a prototype at no charge: a design, a clickable prototype or a working demo on real code, so you decide against something real.
- You receive the system and its source code Custom work is yours from the first commit: the repository, custom modules, theme and deployment configuration. When we build your system on one of our platforms, you receive the whole system and its source code as well.
- A warranty on development work Development projects carry a 1-year warranty by default, up to 3 years. It covers defects in what we built, and applying the security releases of Drupal core and contributed modules while the warranty runs. Maintenance picks up where the warranty leaves off.
- Response targets we publish A first response in 4 hours for critical issues, 1 business day for high priority and 3 business days for normal. Support runs in business hours; cover outside them is an option, priced separately.
Questions we get asked
When is one site with sections enough?
When the units share editors, navigation and an address, and none of them needs an identity or a release timing of its own. A section per unit inside one site costs less to run than a family of sites, and we will recommend it when it fits.
Can a site leave the family later?
Yes, and how easily depends on the architecture. A site built from a shared distribution already has its own code and database. A site in a Drupal multisite has its own database and is split out with a copy of the code. Either way the code is yours, so leaving is your decision to make.
How do security releases reach every site?
On shared code they are applied once and reach every site at the same time. On sites built from a shared base they are released to each site in turn, from one tested change. In both cases the release is tested on the reference site first.
Can each site have its own domain and look?
Each site can have its own domain or subdomain, its own logo and its own colours within the brand rules, drawn from the shared design system. How far a site may change is written into the shared-and-local agreement, so an exception is argued once rather than site by site.
Do the sites share user accounts?
That is a choice made for each family. Shared sign-in suits staff who work across several sites; separate accounts suit sites with separate audiences, such as a public portal and a staff intranet. MineCourt, one of our platforms, lets city-level sites connect to a central hub with single sign-on, which is one way of doing it.
Can content published on one site appear on the others?
Yes. News, events or documents can be published once and shown on several sites, either because the sites share a database or through a feed between them. What travels is agreed in advance, so a unit knows which of its items will appear elsewhere.
We already have separate Drupal sites. Can they be brought onto one base?
Yes, in stages. Each site's content model is compared with the shared one, then sites move in waves: each unit migrates its own content against a standard checklist and launches when its trial run reconciles. A site still on Drupal 7 goes through migration on the way.
Not covered here? Ask us directly.
List your sitesAn engineer reads it and replies within one business day.
Build
Related services
- Custom Drupal Development
- Enterprise Website Development
- Custom Web Application Development
- Software Product Development
- Drupal Intranet and Portal Development
- Drupal Website Redesign and Theme Rebuild
- Drupal Commerce Development
- Headless and Decoupled Drupal
- Drupal Module Development and Porting
- UI/UX Design for Web Platforms
- AI Development for Drupal and Web Platforms
- Outsource Drupal Development
Tell us which sites should share a platform
List the sites or units, who edits each one and what they must have in common. We will say whether multisite, a shared distribution or one site fits, before quoting.
An engineer reads it and replies within one business day.