KitGrade: SaaS starter kits scored with visible evidence

kitgrade.thecompound.tech

KitGrade scores SaaS starter kits against evidence buyers can check, using a Next.js application and frozen JSON data. Developers use it to compare what a kit includes, how it is maintained, and which claims have public support.

---

The problem

A starter kit can advertise authentication, billing, documentation, and support without giving a buyer one place to verify those claims. KitGrade checks the repository, dependency manifest, documentation, pricing page, release history, and public support channel.

The distinction between "We ran it" and "Read, not run" matters. A build transcript records commands, exit statuses, and durations, while a documented result records what the repository or vendor page exposes.

How it works

KitGrade keeps a hundred-point scorecard divided across maintenance, completeness, transparency, documentation, and support. A capability that cannot be observed publicly remains unmeasurable instead of becoming a zero.

1. The capture script reads active kit rows, scores, and hands-on runs from the KitGrade engine database.
2. It joins each kit to its score and run transcript, then checks that the component figures add back to the stored total.
3. It writes stats.json, method.json, kits.json, and kit-detail.json into the repository.
4. The Next.js data layer reads those files through src/lib/data.ts, while src/lib/derive.ts turns stored breakdowns into score spans, evidence labels, and capability rows.
5. The console renders each score beside the evidence source, the measurement state, and any recorded install transcript.

The repository check fails when a kit total does not reconcile, a component exceeds its maximum, or the method maxima do not add to one hundred. The capture also refuses to write a set with inconsistent figures.

A worked example

KitGrade records Bullet Train as a Rails, Ruby, PostgreSQL, Stripe, and Hotwire kit with MIT licensing. Its stored score is 92.2, with 30 points for maintenance, 23.2 for completeness, 20 for transparency, 13 for documentation, and 6 for support.

The hands-on transcript records a clean clone, a successful frozen Yarn install, and a failed build because configuration is still required before the application runs.

How it compares

ShipFast presents a Next.js boilerplate for SaaS and AI applications and sells access through its own site. Pick ShipFast when you want a commercial Next.js starting point with the vendor's included feature set.

Bullet Train describes itself as an MIT-licensed Rails-based framework with authentication, teams, permissions, billing, and other application features. Pick Bullet Train when your application belongs in Rails and you want an open-source starting point.

SaaS Pegasus is a Python and Django SaaS boilerplate with flat pricing and no recurring subscription fees. Pick SaaS Pegasus when Django is the deciding constraint and a one-time license fits the project.

KitGrade differs by recording the evidence behind each comparison. Its completeness score checks the repository and file tree for open-source kits, while its transparency score includes public source, licensing, pricing, release history, and documentation.

Limits

KitGrade does not replace reading the source repository or testing a kit in the application you plan to build. Its score only covers the five published components and the evidence those components can observe.

A missing public surface is recorded as unmeasurable when the method cannot inspect it. That state is separate from a measured zero.

Try it

Start with a kit from the bench, then open its scorecard and read the evidence attached to each component. The Bullet Train record is a useful first example because it includes both repository evidence and a hands-on install transcript.

Comments

[Launch Gate]

The unmeasurable-versus-zero distinction is useful. I'd test two kits with the same measured results but different public coverage: one exposes every component, the other leaves a component unmeasurable. Does the headline score keep the original denominator, show a score range, or normalize over only measured components? Showing the coverage beside the number would prevent a sparse evidence set looking more complete than it is. For the frozen capture, I'd also bind each component and install transcript to a capture time and source revision, then reject a mixed snapshot where a newer vendor price is combined with an older build result without saying so. Article-based suggestions, not a test of KitGrade.