A boilerplate is a bet that someone else’s foundation will hold while you build on it. Most of that bet is invisible at purchase, because the demo always looks clean. Rot shows up later: the framework goes a major version behind, a dependency has a CVE nobody patches, the one maintainer stops answering, and you are now the maintainer of code you did not write and do not fully understand.
This audit is the checklist for making that bet with open eyes. It is seven signals, each scored, run before you commit. It works whether you are evaluating a paid kit, an open-source starter, or your own team’s internal template. The goal is not a perfect score. It is knowing exactly which debts you are agreeing to carry.
Signal 1: dependency freshness
Open the lockfile before you open the README. The lockfile does not market. It tells you the true age of the foundation.
- What major version of the framework is it on, and how far behind current is that?
- Are the core libraries (the database client, the auth layer, the payment SDK) current, or pinned to versions with known advisories?
- How many dependencies are unmaintained, judged by their own last release date, not the kit’s?
A kit one major version behind is not disqualifying, but it is deferred work you are agreeing to do. Two majors behind on the framework is a rewrite hiding in the future. Score it before you find out the hard way. The remaining six signals below are the part that separates a kit that ages well from one that becomes your problem: the RLS read, the migration story, the lock-in price, the bus factor, the license, and the test surface, each with a scoring band and a red-flag list. Unlock the full rubric with your email and download it as a Markdown scorecard.
Signal 2: read the RLS, not the README
This is the signal that separates a serious kit from a demo. Open the SQL. Multi-tenant isolation is either enforced in the database or it is a sentence on a sales page. You are looking for three things.
- Is Row Level Security enabled on every table that holds tenant data, or only mentioned in prose?
- Are the policies org-scoped (membership-based), or is every read a blanket USING (true)?
- Is there a real tenancy helper the policies share, or is the isolation logic copy-pasted and inconsistent across tables?
If you open the schema and every policy predicate is USING (true), the kit has RLS enabled for the compliance checkbox but enforces no actual tenant isolation in the database. That is worse than no RLS, because it looks safe. The full failure-mode breakdown is in the sibling Multi-Tenant RLS Security Checklist; run a kit’s SQL through it before you trust it.
Signal 3: the migration story
A kit you cannot update is a kit you will fork and abandon. The question is whether schema changes arrive as something you can apply, or as a wall.
- Green: idempotent, versioned migration files (each CREATE guarded by IF NOT EXISTS, numbered in order) that you can run and re-run safely.
- Yellow: migrations exist but are not idempotent, so applying an update risks colliding with your changes.
- Red: a single schema dump with no migration path. Every future update is a manual diff you do by hand.
The idempotent-versioned pattern is what lets a kit ship you an update six months in without breaking the tables you have since customized. It is the difference between a living foundation and a snapshot you are stuck with.
Signal 4: the lock-in price
Ask what you would have to rip out to leave. The answer is the true cost of adoption.
- Green: standard, portable substrate (plain Postgres, a mainstream framework, standard auth) that you could self-host or move.
- Yellow: leans on one managed service but through a swappable interface.
- Red: the whole kit is a thin wrapper around a single proprietary API, and the API is the product. You are not buying a foundation, you are renting a dependency with extra steps.
Signal 5: bus factor and maintenance signals
The most common way a kit dies is quietly: the maintainer moves on and stops answering. You can read the future in the public record.
- When was the last real commit, ignoring version bumps and typo fixes?
- How long do issues sit open, and does the maintainer answer them or only close them?
- Is there more than one person who understands the codebase, or is it a single point of failure?
- Is there a changelog that shows the kit is actively evolving, not just being sold?
Signal 6: license
Read the actual license, not the pricing page’s summary of it.
- Can you modify it freely and ship it in a commercial product?
- Is it a permissive open-source license (you own your fork), or a proprietary license that restricts resale, redistribution, or the number of projects?
- If the vendor disappears, are you still legally clear to keep using and modifying the code?
Signal 7: the test surface
Tests are not about coverage percentage. They are about whether you can change the code without fear.
- Are the load-bearing paths (auth, tenancy, payment webhooks) tested at all?
- Do the tests actually run, or are they present but broken?
- When you make a change, does anything tell you that you broke something, or do you find out in production?
Scoring
Score each of the seven signals green (2), yellow (1), or red (0). These bands are a working convention to force a decision, not a precise metric.
- 11 to 14: a foundation you can build on. Note the yellows as debts you have chosen to accept.
- 7 to 10: usable, but go in knowing you will be doing meaningful maintenance yourself. Price that time in.
- 0 to 6: a demo, not a foundation. Any red on RLS, migrations, or license alone is enough to walk, whatever the total.
A red score on tenant isolation (Signal 2), the migration story (Signal 3), or the license (Signal 5) overrides the total. A kit can be excellent everywhere else and still be the wrong bet if it leaks tenants, cannot be updated, or legally traps you. Those three are pass or fail before you add anything up.
Read the rest and take it with you
The full guide plus a downloadable Markdown copy. One email, no wall on the preview above, unsubscribe any time. You also get the occasional build note when we ship something worth your inbox.