Methodology
Every verdict on kitproof comes from public evidence you can check yourself. No hidden scores, and nothing is for sale.
Maintenance pulse
From commits on each kit's default branch, via the GitHub API.
| Active | Commits in the last 30 days |
| Steady | Commits in the last 90 days, none in the last 30 |
| Slowing | No commits in 90 days; last one within 6 months |
| Dormant | No commits in over 6 months |
| Archived | Archived by its owner |
| Not verifiable | No public repository to check |
Dependency freshness
We read the kit's package.json (including pnpm catalogs) or, for Python kits, its pyproject.toml andrequirements.txt, take the lowest version each core dependency allows, and compare its major version to the npm "latest" release or the newest PyPI release. Core dependencies include Next.js, React, Tailwind CSS, Prisma, Drizzle, Auth.js, Better Auth, Supabase, tRPC, Zod, the Vercel AI SDK, Astro, SvelteKit, and Expo; for Python, Django, Flask, Pydantic, SQLAlchemy, Celery, LangChain, and similar. For 0.x packages, any minor-version gap counts as one breaking step.
| Current deps | Core dependencies on their latest major version |
| 1 major behind | At least one core dependency is one breaking release behind |
| 2+ majors behind | A core dependency is two or more breaking releases behind |
| Deps unknown | Dependencies not publicly verifiable |
TypeScript and the Stripe SDK are shown but not counted. Their major releases rarely change what a buyer gets: TypeScript 7 is a compiler rewrite, and Stripe SDK majors follow Stripe's API-version schedule.
Grades (A–F)
The grade is not a separate score. It's a fixed lookup from the two verdicts above, so you can always see exactly why a kit got its letter. Nothing else goes in: not stars, not popularity, and never money.
| Maintenance ↓ / Dependencies → | Current deps | 1 major behind | 2+ majors behind | Deps unknown |
|---|---|---|---|---|
| Active | A | B | C | B |
| Steady | A | B | C | B |
| Slowing | B | C | D | C |
| Dormant | D | D | F | D |
| Archived | F | F | F | F |
- Not graded (–): closed-source kits with no dated public pages. We don't grade what we can't see.
- Grade with a dashed outline and *: based on the vendor's own public pages (changelog, pricing), not verified code.
- Kits are ranked by grade first, then by the maintenance and dependency order below, so rank never contradicts the letter.
Ranking
Within each category, kits are ordered by:
- Grade (A → F; not graded sits between C and D)
- Maintenance pulse (active → steady → slowing → not verifiable → dormant → archived)
- Dependency freshness (current → behind → unknown → stale)
- Commits in the last 90 days
Never used: GitHub stars (they're easy to fake), commissions from sponsored links, sponsorships, or paid placement. Sponsored placements, when we have them, are labeled and shown separately from the ranking.
Receipts: check our work
Every reason on a kit page has a receipt link to the raw record it's based on: the commit list for the window we counted, the exact release tag, or the package.json a version came from. For open-source kits we record the commit we read (the "snapshot"), and receipts point to files at that exact commit, so they stay valid even after the repo changes. Vendor claims link to the vendor's own changelog or pricing page. If a receipt doesn't back up the claim, tell us: that's a bug.
For kit makers
Closed-source kits show "Not verifiable" because we can't see the code. That is not a judgment of quality. You can get verified by giving us read-only access to your repository or a public changelog, and you can correct factual errors at any time. You can't remove accurate evidence or buy a better verdict.
Data for tools and agents
Everything on the site is also available as JSON: /api/kits.json for all kits, or/api/kits/<id>.json for one. There's an RSS feed of changes and anllms.txt for AI assistants, plus an MCP server so coding agents (Claude Code, Cursor, and others) can check a kit before recommending it: tools check_starter_kit, find_starter_kits, and compare_starter_kits. Free to use with attribution and a link to each kit's evidence page.
Limits
- Commit counts measure activity, not quality. A finished, stable kit can be quiet.
- Detected stack items mean a package is installed, not that the feature is complete.
- "No license detected" means GitHub couldn't identify one. Read the repository before commercial use.
- Evidence is refreshed on a schedule. Each page shows when it was last checked.