Safeguard
Security Guides•

What should you clean in a starter template before reusing it for a client?

Starter templates carry old dependencies, keys and config. A pre-use checklist for agencies: update, scan, remove secrets, and reset identifiers.

Safeguard Security Team
3 min read

Before you reuse a starter template, update and audit its dependencies, remove leftover secrets and identifiers from the last project, reset analytics and auth settings, check the runtime version, and delete unused features. A template is a snapshot, and it begins aging the day it was saved.

What goes wrong

Agencies keep a starter repo to move fast. Six months later someone clones it for a new client. The template still pins old packages, still has a sample config with a real looking key, and still includes the analytics snippet from a previous client's account.

None of this is exotic. It is what happens when copying is easier than checking.

The checklist

  1. Update dependencies. Run the update tool, then the test suite. Do not ship a template's lockfile as is.
  2. Audit. Check the updated tree against known advisories and review any package that has been abandoned.
  3. Check the runtime. Look at the Node, PHP, Python or Java version in the template and CI config, and make sure it is still supported. The engines field in npm is advisory only unless engine-strict is set, so it will not stop a mismatch for you.
  4. Search for secrets. Look through the files and the git history for keys, tokens, passwords and private URLs. If history is polluted, start a fresh repository from the files, not the history.
  5. Reset identifiers. Analytics IDs, tag manager containers, OAuth client IDs, error tracking projects, webhook URLs, email senders.
  6. Remove sample data and test accounts. Default admin users are the classic mistake.
  7. Delete what the project will not use. Unused auth providers, example routes, demo pages.
  8. Rewrite the README and CI. They should describe this client's project.
  9. Reapply security defaults. Branch protection, required reviews and a dependency update config do not copy with the files.

Keep the template itself healthy

  • Give it an owner and a review date.
  • Run the update tool on the template repo, so each new project starts closer to current.
  • Keep a short changelog so people know what changed between clones.
  • Write the checklist above in the template's README, not in a wiki nobody opens.

A repository template creates new repositories from a snapshot. Repos already created do not update when you change the template, so older client projects need their own update path.

When a template is a liability

If it has not been touched in a year, rebuild it from a fresh scaffold rather than patching. Compare the work to cleaning a dozen small problems every time someone clones it.

Quick check

Is it fine to copy an old client project as a template?

Avoid it. Client code, data and keys can leak into the next project. Start from a clean generic template instead.

How often should the template be refreshed?

Set a calendar review, for example quarterly, and refresh after any major framework release.

Sources

Last reviewed: 19 October 2026.

Never miss an update

Weekly insights on software supply chain security, delivered to your inbox.

Self-healing security runs on Safeguard.

Your first fix PR is minutes away.

No sales call required, even your agent can complete the purchase over MCP.