The Agency Base Template: Build It Once, Charge For It Every Month

Almost every agency that has been building for more than a year or two has one, and almost none of them treat it as a thing they own. It is the site you copy from. A set of layouts, snippets, form handlers, module configurations and a dozen small conveniences that solve the problems every project brings — navigation, a contact form that actually notifies the right person, the login state check you always need, the SEO fields you always forget. It gets carried into the next job, quietly improved, carried again.

Two things are usually true about it at the same time. It is the single highest-leverage asset the agency owns, and nobody has ever put a price on it. This piece is about both halves: what a base template should contain, which parts of it actually travel between client sites on WebinOne, and why the way most agencies bill for it caps what a small studio can earn.

What is an agency base template?

It is your default starting point for a new project — the accumulated answer to "how do we build a site", expressed as working code and configuration rather than as a document nobody reads. Not a design. A design is per client. The base is everything underneath the design that does not change from client to client.

The distinction matters commercially, because a design is something you sell once and a base is something you can sell every time you use it. Most agencies get this backwards: they charge for the design, which took a week, and give away the base, which took four years.

What actually belongs in one?

Everything you have written more than twice. In practice that means the page layouts and the partials they pull in; the navigation, header and footer; the form set with its confirmation and notification emails; the module structures you always end up creating — team members, testimonials, locations, case studies; the error and system pages, which are the classic thing nobody remembers until launch week; your analytics and consent wiring; and the small logic helpers that are pure time — checking who is logged in, formatting dates the way clients expect, rendering a list of related items without rewriting the loop.

What does not belong in it is anything you would have to explain to a colleague as "that was for the museum client". A base template earns its keep by being general. The moment it starts carrying one project's compromises it becomes a fifth site to maintain.

Which parts of a WebinOne site actually travel between projects?

Most of the front-end layer, because it is files. Our documentation is explicit that content assets are accessible both through the admin and over FTP, and it names them: Content Templates, Email Templates, Forms, Snippets, System Pages, System and Custom Emails, and module Layouts. If it is one of those, it is a file you can keep in version control, diff against last quarter's version, and push into a new site the same way you would push it into a repository.

The structural layer travels too, but through a different mechanism. Custom Modules — our object model, the thing you define when a project needs a content type the platform does not ship with — have their own import, export and duplication features. The documentation is worth quoting on what that actually copies: "Import/Export of Modules will also duplicate nested module configurations, creating both the parent and child modules assigned in the settings", and the export "does not contain the module's items", which is to say it carries the structure and not the content. That is the correct behaviour for a base template. You want the shape of the module, not the museum's opening hours.

Two honest limits on that. The docs state that import, export and duplication of modules are available on PRO content plans only, so the plan you put a site on decides whether this part of your base moves in one action or by hand. And the file system is case-sensitive, which matters the first time you push a folder of files from a machine that was not.

How do you start a new site from your own base?

A new trial site is created from the Portal, and one of the fields at creation is the template: a blank site, or one of the free WebinOne templates. Our documentation states the wider position plainly — "Not only can you build your websites from your own custom code, framework or 3rd party templates, but you can also get started quickly by choosing from one of our beautifully designed, responsive templates". The platform has an opinion about how content is structured and no opinion at all about how your front end is built.

So the practical sequence for an agency with its own base is: create the site blank, push your file layer, import your module definitions, then design on top. The free templates are still worth knowing — the templates page currently lists 26 available, and every one of them is compatible with the On-Site Editor, which makes them a reasonable starting point for a client who wants to edit their own pages and a reasonable source of patterns for the base you are building.

Why does the project model cap what your base template earns?

Because a project fee is paid once for something you will use twenty times, and the client who pays it does not know they are buying it. You quote a build. The base makes the build take three weeks instead of six. The client pays for three weeks. You have just converted four years of accumulated work into a discount.

That is not an argument for charging more per project — clients compare build quotes, and the base is invisible in that comparison. It is an argument for the base being a different line on the invoice, and a recurring one.

How do you turn a base template into something you charge for monthly?

By selling what the base actually delivers after launch rather than at launch. The site keeps working, keeps being editable, gets the improvements you make to your base as you make them, and has someone who knows it on the other end of an email. That is a product, and it is priced monthly everywhere except in the agencies that build it best.

The commercial mechanics on our side are built for that rather than against it. Our pricing page states that the published plan pricing "is designated for web design resellers" and that "site owners and free users expect at least 2x markup" — you buy at the reseller line and set your own retail. The reseller programme is white-label: "White-label all of the sites under your brand", with granular white-labeling, branded subdomains, and "direct billing is available" if you would rather the client pay the platform directly on your commission pricing than run every invoice through your own books. WebinOne does not publish a fixed commission rate, which is the part worth noticing: what you charge for the care plan is a pricing decision you make, not a margin handed to you.

Three things a care plan built on a base template can honestly include: platform and hosting, which you are not maintaining because we are; ongoing improvements to the base, which every client site inherits when you push them; and a fixed monthly allowance of changes, which is the part clients actually value and the part that stops the "quick favour" email from being unpaid.

What does the platform have to provide for this to work?

Uniformity, mostly. A base template pays off in proportion to how identical your client sites are from the inside, and it stops paying the moment three of them are on three different stacks with three different hosting accounts and three different update schedules.

Our platform overview puts the platform side of that in one sentence: "All features are native extensions built and maintained by the WebinOne team." The management side is the Portal — the same page publishes that "Partners manage all client sites from a single centralized portal", with each site keeping its own domain, template and configuration while billing, support and user management stay consolidated. That is what makes an improvement to your base a thing you roll out rather than a thing you schedule.

Where does AI fit, and where does it not replace the template?

It fits exactly where the base template already sits, which is why it is worth mentioning here rather than in a piece of its own. AgentOne, our agent system, is built in three layers, and the middle one is a direct description of what a good base template is: Partner Agents are "your agency's layer", where "your own skills, design patterns, preferred configurations" live, and the page states the intent in five words — "Build a pattern once, deploy across every client site." The same page is blunt about what that is worth: "Your methodology becomes a reusable, sellable asset."

What it does not do is invent the methodology. An agent trained on your patterns needs patterns; the agencies that will get the most out of this layer are the ones that already have a base template, because they have already done the hard part of deciding how they build. AgentOne is in Partner Beta and available to licensed Partners, and the control model is worth reading before you plan around it: everything runs in draft mode with nothing published without approval, a backup is taken before every modification with one-click rollback, and the activity log records what changed and when. The details are on the Managed Vibe Coding page.

What are the limits worth knowing before you build one?

A base template is a product with an owner, and if that owner is nobody it rots. Somebody has to decide what goes in, what comes out, and what happens when a client project needs the base to change. Small agencies usually get this wrong in the same direction: the base becomes whatever the last project needed.

The other three are practical. Module import and export sit on PRO content plans, so check the plan before you promise yourself a one-click setup. Content does not travel with structure, so the demo data in your base is yours to recreate or to import separately. And the sites already in your care were not built from your base — bringing them onto it is a rebuild decision, not a copy, which is a separate question covered in inheriting a client site.

How do you actually start?

Take the last three sites you built and open them side by side. Every file that is identical in all three belongs in the base; every file that is nearly identical is a decision you have been making three times. That exercise usually takes an afternoon and produces about eighty per cent of a base template, because the work is already done — it is just distributed across projects instead of collected in one.

Then build it as a site rather than as a folder. Create a trial site in the Portal, put the base in it, and treat it as the thing you copy from and improve rather than as an archive. And price it before you use it on the next client, because it is much harder to add a monthly line to a relationship that started without one.

If you are building this way already and want the platform side of it — one portal, white-label, direct billing, per-site plans — the reseller programme is where that starts, and the development overview is the shortest description of what you can build on top.