Skip to main content
Skip to content

Resources

Template licences for agencies: what client-work buyers need to check

Last updated 24 May 2026 · Dan Tinsley, Halbon Labs

A SaaS template can save an agency weeks. A licence misunderstanding can cost far more than the template.

Agencies, freelancers, studios, and product teams use boilerplates differently from solo founders. They may build for clients, transfer code, collaborate with contractors, reuse internal libraries, deploy multiple projects, or maintain client products after handoff.

That means the licence matters before the first commit.

This is not legal advice. It is a practical checklist of questions to answer before using a paid template in commercial work.

Start with the real use case

Do not ask “is commercial use allowed?” too vaguely.

Ask what you actually plan to do:

  • Build your own SaaS.
  • Build a client SaaS.
  • Build multiple client projects.
  • Build an internal company tool.
  • Use contractors.
  • Share the repo with a client team.
  • Transfer ownership after delivery.
  • Reuse components across projects.
  • White-label the result.
  • Sell a derivative template.

Most licences allow some of these and restrict others.

Client work is the first agency question

If you are an agency, check whether you can use the template in paid client deliverables.

Important details:

  • Is one licence valid for one client project or unlimited projects?
  • Can the client receive the source code?
  • Can the client continue using the code after the agency engagement ends?
  • Can the client modify the code?
  • Does the client need their own licence?
  • Can the project be deployed under the client’s brand?

Do not assume that “commercial licence” automatically covers agency delivery.

Seat rules can affect teams and contractors

Some licences are per-person. Some are per-company. Some are per-project. Some allow contractors only while working for the licence holder.

Ask:

  • How many developers can access the source?
  • Can contractors access it?
  • Can the client’s developers access it?
  • Does access need to be removed after delivery?
  • Are designers or project managers counted?
  • What happens when team members leave?

This matters for GitHub access, handoff, and compliance with the seller’s terms.

End users are different from developers

Many template licences allow unlimited end users in the finished SaaS product. But you should confirm.

There is a big difference between:

  • people who use the final app;
  • people who can access the template source;
  • people who can reuse the template in new projects.

A good licence makes this separation clear.

Redistribution is usually restricted

Most paid template licences prohibit redistributing the template itself.

That usually means you cannot:

  • resell the template as a template;
  • publish the source code publicly;
  • create a competing boilerplate from it;
  • share the original files with people outside the licence scope;
  • upload it to a public repository.

This is reasonable. The important thing is knowing where the boundary is between a permitted finished product and prohibited redistribution.

White-labelling needs explicit permission

Agencies often need to remove template branding, replace design language, and deliver under the client’s brand.

Check whether the licence allows:

  • removing seller attribution;
  • changing all branding;
  • using in white-label client products;
  • using in internal tools;
  • using in products sold to many customers.

If attribution is required, make sure the client knows before delivery.

SaaS, internal tools, and client portals may be treated differently

A licence may distinguish between:

  • public SaaS products;
  • internal company tools;
  • client portals;
  • marketplace products;
  • hosted services;
  • downloadable software;
  • resale of generated apps.

Your project type should be clearly allowed.

Support and updates may not transfer

Even when source use is allowed, support rights may stay with the original buyer.

Ask:

  • Who receives updates?
  • Can the client contact support?
  • Does support cover agency customisations?
  • Are bug fixes included forever or for a fixed term?
  • Are major upgrades included?
  • Can updates be applied after client handoff?

This affects maintenance planning.

Licence clarity affects procurement

Larger clients may ask:

  • Who owns the final deliverable?
  • Are third-party licences documented?
  • Can we audit dependencies?
  • Are there restrictions on our use?
  • What happens if the agency relationship ends?
  • Can we continue development internally?

A clear template licence makes these conversations easier.

Keep a licence record per project

Agencies should keep a simple record:

  • template name;
  • version used;
  • purchase date;
  • licence holder;
  • project/client;
  • developers with access;
  • link to licence terms;
  • any seller clarification emails;
  • update rights;
  • support scope.

This is boring, but it prevents future confusion.

Licence audit checklist

Before using a template for client work, check:

  • Client work is explicitly allowed.
  • The number of permitted projects is clear.
  • Source-code handoff rules are clear.
  • Contractor access is allowed or controlled.
  • Client developer access is allowed if needed.
  • End-user limits are acceptable.
  • White-labelling is allowed.
  • Redistribution restrictions are understood.
  • Support rights are clear.
  • Update rights are clear.
  • The licence survives project handoff if needed.
  • Third-party dependencies have compatible licences.
  • You have stored a copy of the licence terms.

Template Empire angle

Template Empire is built for founders, solo developers, agencies, and product teams, so the licence answers the agency questions above directly rather than in vague terms. Every Template Empire purchase is a perpetual, non-exclusive licence with the full unobfuscated source and the freedom to modify it.

For agency and client work the model is deliberately simple: one licence covers unlimited projects, including the ones you build for clients. You do not buy a new licence per engagement; you can build and ship as many client apps from a single purchase as you want. Team access is built in too, so your employees and contractors can work on the source without separate seats.

The one boundary to brief your team on: sell the product you build, not the template you built it with. Deploying a client SaaS and billing for it is the intended use; repackaging the source as a starter kit, theme, or boilerplate, or handing a client reuse rights to the template itself, is not. When you deliver to a client they receive the finished product, not a licence to reuse the template for their own future work.

Support is lifetime email support on every purchase, covering bug reports, setup, and upgrade guidance, without SLAs or custom development. The full terms are on the licence page; read them before you commit a template to paid client work.

Further reading