How to run a productised website service
A productised website service sells a fixed site at a fixed price. How to package one without it becoming a custom build in disguise by the third client.
Most agencies that try to productise end up with a price list and a custom build. The first client gets the package. The second gets the package plus a booking widget. By the third, the "fixed" site has its own content model, its own sections and its own quirks, and the only thing that's productised is the invoice.
A productised website service sells a fixed site, at a fixed price, through a fixed process. It's a real business model, and it works for a lot of agencies. It just doesn't survive contact with good intentions unless you decide in advance what's fixed and what isn't.
What productising actually means
Four things stay the same for every client.
The content model. The same content types, the same fields, the same relationships. A dentist and a solicitor both get services, team members, a contact page and news.
The section library. A fixed set of sections the client can compose pages from: a hero, a feature grid, testimonials, a call to action, a form. They choose which and in what order. They don't get new ones.
The process. The same kick-off questions, the same content deadline, the same review round, the same launch checklist.
The price. Published, or at least identical for everyone.
Two things vary: the content and the brand. Words, images, colours, type, logo. That's the whole surface of variation, and it's enough. Most small-business clients care far more about their own words and their own colours than about a bespoke grid.
The parts that have to be reusable
Productising is mostly an engineering problem disguised as a sales one. If every build starts from an empty project, you're not running a product, you're running a fast agency.
You need three reusable assets. A content model you can apply to a new site in one step. A theme that renders every section and every page type from that model. And a set of design tokens, colours, type scale, spacing, that a new brand can be dropped into without touching templates.
The theme is where most attempts fall apart. If brand changes mean editing templates, each client's theme slowly forks. Keep brand in tokens and theme settings, keep layout in templates, and never let the two mix. Liquid themes explained covers why one theme can render every page from content.
On Contentive this maps onto things the platform already has: a saved content model as the starting point for each new workspace, a Liquid theme kept in your own git and pushed to each site's staging with the CLI, and sections defined once as reusable stacks. A new client is a new workspace, the saved model, the theme, and their brand. Setting up a new client becomes a configuration job, not a build.
Where productised services die
They die on "just one custom thing".
It's always reasonable. The client needs a menu page because they're a café. They need an events list because they run workshops. They need the hero to be a video. Each request is small, and each one is a fork.
The cost isn't the build. It's that this site is now different from the others forever. The next theme update has to be tested against the café menu. The next model change has to consider the events list. We made the same point about plugin maintenance: every one is a decision you keep making.
There are two honest responses. Turn the request into an add-on, designed once and offered to every client from then on. Or say no and refer them to the custom service. "Just this once" isn't an option, because it's never just once.
Pricing the product
A structure that works for most agencies:
A fixed build fee. One price for the standard site. It includes a set number of pages, the content load if you do it, and one round of review.
A care plan. Monthly, for hosting, updates and a small allowance. We wrote about pricing maintenance from cost.
Named, priced add-ons. An events section. A booking page. A second language. Each has a name, a price and a fixed scope, and each was built once and reused.
The add-on list is where the product grows. When three clients have asked for the same thing, build it properly, add it to the list and price it. When one client asks, quote it as custom work.
Keep the build fee honest. If the standard site regularly takes longer than the price assumes, the price is wrong, not the client.
What you give up
You turn work away. A productised service is a statement about who you're for, and some clients won't fit. The café with an unusual menu, the charity with three audiences, the client who wants it to feel "nothing like a template". Some of them would have been good projects.
You also give up some of the craft. Designers who like starting from a blank page will find a fixed section library limiting. That's a real cost to morale and to hiring, and it's worth talking about before you commit.
What you get back is predictability: margins you can forecast, a process a junior can run, and sites that are all maintained the same way.
Find the product you already have
Open your last three builds. List the content types, the sections and the pages each one had. Mark everything they had in common. That list is your product, and the things that only appeared once are your add-ons or your custom service. There's a good chance the product was there all along, and you kept rebuilding it from scratch.
If you want a sharper scope conversation with the clients who don't fit, how to scope a website project is the next read.