DEV Community: Samantha Start

What Google Lighthouse Did for Web Performance, We Need for Code Repos

Samantha Start — Fri, 10 Apr 2026 23:33:25 +0000

Remember before Lighthouse? Web performance was a black box. You knew your site felt slow, but you didn't have a standardized way to measure it, benchmark it, or explain it to stakeholders.

Lighthouse changed that. One URL, one score, actionable breakdown. Suddenly performance was a conversation everyone could have, not just the senior engineer who profiled Chrome DevTools.

Code repos have the same problem today

Most developers can tell you whether a repo 'feels' well-maintained. But there's no standardized score. No quick way to benchmark. No shared language between the developer who maintains it and the manager who funds it.

The signals exist — CI pipelines, test coverage, dependency health, branch protection, type safety, dead code, security — but nobody aggregates them into a single, comparable number.

Why this matters now

Two trends are colliding:

AI coding tools are producing repos faster than ever. Claude Code, Cursor, Windsurf — developers are shipping in hours what used to take weeks. But the AI focuses on working code, not operational readiness.
Open-source dependency chains are deeper than ever. When you pick a starter template or library, you're inheriting its infrastructure patterns. If it has no tests and no CI, neither will your project — unless you add them yourself.

The gap between 'working code' and 'production-ready code' is getting wider, and there's no standard way to measure it.

What a Lighthouse for repos looks like

We built RepoFortify to be that standard. Paste a public GitHub URL, get a score out of 100 across 9 signals:

CI pipeline (15%)
Test coverage (25%)
Dependency health (10%)
Branch protection (10%)
Type safety (10%)
Dead code (10%)
Exposed routes (5%)
Documentation (10%)
Security headers (5%)

No signup, no paywall for public repos. We also ship an MCP package (npx @repofortify/mcp) so AI coding tools can run scans inline.

The goal isn't to shame anyone. It's to give teams a shared language for production readiness — the same way Lighthouse gave teams a shared language for performance.

We Scanned 6 SaaS Starter Templates — Here's What We Found

Samantha Start — Fri, 10 Apr 2026 21:15:55 +0000

Starter templates promise a head start. But how production-ready are they out of the box? We scanned 6 popular templates across Next.js, Remix, and SvelteKit using 9 production readiness signals.

The 9 Signals

Our scanner checks: CI pipeline, test coverage, dependency health, branch protection, type safety, dead code detection, exposed routes, documentation quality, and security headers. Each is weighted by impact — tests are 25% of the total score, CI is 15%.

The Results

Template	Framework	Stars	Score
epic-stack	Remix	5,531	89
next-starter	Next.js	974	86
remix-saas	Remix	1,465	84
CMSaasStarter	SvelteKit	2,297	73
chadnext	Next.js	1,323	49
kitforstartups	SvelteKit	734	5

Averages: Remix 86.5, Next.js 67.5, SvelteKit 39.0. Overall average: 64/100.

Key Takeaways

Stars don't predict quality

chadnext has 350 more stars than next-starter but scores 37 points lower. Community popularity measures how many people found something useful, not whether it's production-ready.

Framework ecosystem maturity matters

Remix starters both scored 84+. This isn't coincidence — the Remix ecosystem has strong opinions about testing and CI that flow into community templates. SvelteKit's ecosystem is newer and more varied.

The gap is operational, not code quality

Most of these templates have clean, well-structured code. Where they diverge is CI pipelines, test coverage, dependency management, and branch protection. The 'boring' infrastructure that keeps production stable.

What This Means For You

If you're picking a starter template:

Check if it has CI that actually runs on PRs
Look for any test coverage at all (many have zero)
Check dependency freshness — stale deps = security risk
Consider that the template's infrastructure patterns become YOUR patterns

You can scan any public GitHub repo at repofortify.com — free, no signup.

I Scanned 10 Popular TypeScript Repos — Stars Don't Predict Production Readiness

Samantha Start — Thu, 26 Mar 2026 04:16:32 +0000

I couldn't help myself. I took 10 popular TypeScript repositories — all between 4,000 and 5,000 GitHub stars — and ran them through our production readiness scanner.

The results surprised me.

The Scores

Repo	Stars	Score	What I noticed
mengxi-ream/read-frog	4,941	79/100	Translation browser extension with its infrastructure together. Genuinely impressed.
tagspaces/tagspaces	4,985	77/100	Offline-first document manager. When your app works offline, you have to get the engineering right.
useplunk/plunk	4,933	75/100	Open-source email platform. This is what happens when maintainers treat readiness as a first-class concern.
microsoft/FluidFramework	4,917	72/100	Real-time collab library. Building distributed systems for others to build on — you can't fake the infrastructure.
extension-js/extension.js	4,963	66/100	Cross-browser extension framework. Solid. Building browser extensions is already painful; investing in infra on top shows discipline.
microsoft/tsdoc	4,943	65/100	TypeScript doc comment standard. Expected higher from Microsoft tbh — but it's a spec project, not an app.
opennextjs/opennextjs-aws	4,974	60/100	Next.js adapter for AWS. Someone thought about deployment beyond "it works on my machine."
gluestack/gluestack-ui	4,994	49/100	React/React Native component library. Nearly 5K stars, below 50. The components are gorgeous. The infrastructure has gaps.
tinyplex/tinybase	4,980	44/100	Reactive data store. Clean API, great docs, but infrastructure signals aren't keeping pace with the star count.

What I Learned

Stars don't predict production readiness. At all.

The highest-starred repo in my set (gluestack-ui, 4,994 stars) scored 49. The highest-scoring repo (read-frog, 79) has fewer stars than most of the others.

The repos that scored well had something in common: someone invested in CI, tests, dependency management, and configuration as foundational work, not as an afterthought.

The repos that scored poorly had great code and great docs — but the engineering infrastructure around the code was thin or missing.

The Pattern

Every time I scan repos, the same pattern emerges:

The code is usually fine. Whether human-written or AI-assisted, the application logic works.
The infrastructure is where it breaks. CI pipelines, test coverage, branch protection, secrets management, dependency health — these are the signals that separate "it runs" from "it's production-ready."
Stars measure popularity, not readiness. A repo can have 5,000 stars and still be missing half the production basics.

What We Check

Our scanner looks at 9 production readiness signals:

CI enforcement
Test coverage
Type safety
Dependency health
Branch protection
Dead code
Dead exports
Linter configuration
Route coverage

Each signal is a binary or scored check. No AI-generated suggestions, no hallucinated fixes — just structural verification.

Try It

If you maintain an open-source TypeScript project (or any project, really), I'm genuinely curious how it scores. The scanner is free, no signup required:

repofortify.com

Paste your repo URL, get a score in seconds. I'd love to see what the dev.to community's projects look like.

And if you score above 75 — seriously, tell me. I want to celebrate the repos that are doing it right.

Samantha Start builds production readiness scanning tools at RepoFortify. She scans too many repos and can't stop talking about what she finds.

Two Types of AI Code Debt — And Only One Is Scannable

Samantha Start — Wed, 25 Mar 2026 16:14:26 +0000

After scanning 200+ repos built with Claude Code, Cursor, and Copilot, we've identified two distinct types of debt:

1. Structural Debt — Scannable and Fixable

Missing CI pipeline, zero test coverage, hardcoded secrets, unmanaged dependencies. This is measurable:

73% of AI-built repos have no CI pipeline
68% have zero tests
41% have hardcoded secrets

These are binary checks. Either CI exists or it doesn't. Either secrets are in env vars or they're hardcoded. A scanner can catch all of this.

2. Comprehension Debt — Harder to Measure

Code that works but nobody understands because nobody wrote it with intent. AI generates 200 lines where 40 would do. The abstractions are illogical. The reviewer's eyes glaze over.

This debt compounds because each untested module interacts with other untested modules. The failure modes multiply faster than the code volume.

The Gap

Most teams don't realize they have both types until the first production incident. By then, the structural debt has made the comprehension debt impossible to diagnose.

We built RepoFortify to catch Type 1 — the structural gaps that AI coding tools consistently skip. It checks 9 production readiness signals in seconds.

Type 2 is the next frontier. But you can't fix comprehension debt if your CI is broken and your tests don't exist.

Start with structure. The rest follows.

Free scan: repofortify.com — paste your repo URL, get a production readiness score across 9 signals. No signup required.