DEV Community: Samantha Start

You built an app with AI this weekend. Here are the security holes it probably has.

Samantha Start — Sun, 12 Jul 2026 00:13:52 +0000

You had an idea on Friday. By Sunday you had a working app. The AI wrote most of the code, you wired it together, and it just worked.

Here is the part nobody says out loud: you did not read every line the AI wrote. Almost nobody does. That is fine, it is how building works now. But it means there are probably a few security holes sitting in your app that you cannot see, because you never looked at the code that made them.

The good news: the most common holes in AI-built apps are a short, predictable list. You can check for them in about 15 minutes. Here are the three that cause the most real trouble, in plain terms.

1. A secret written straight into the code

AI assistants love to put your API key or database password right in the code to make things work. It runs great. The problem shows up later: that secret ends up in your git history, and public repos get scanned by bots within minutes of going up.

Deleting the line does not fix it. The secret still lives in your past commits. Anyone who clones the repo can read it.

How to check: search your code for anything that looks like a key or password. If you find one, or if one was ever committed, rotate it now (create a new one, revoke the old), then move secrets into environment variables instead of the code.

2. An API route with no lock on the door

When the AI builds a route that returns data, it often does not add a check for who is asking. It works in testing because you are the only user. Then it ships, and anyone who finds the URL can pull the data.

How to check: for every route that returns user or account data, confirm there is a login or permission check in front of it. If a route hands back private data to anyone who asks, that is the first thing to fix.

3. A public default that should be private

Storage buckets, databases, and file uploads often start with a default that is more open than you meant. The AI picks a setting that works, not the one that is safe. So your uploads or your database might be readable by the whole internet without you knowing.

How to check: look at your storage and database settings. Anything holding real user data should be private by default, with access granted on purpose, not by accident.

The 15-minute pre-launch checklist

Before you put your app in front of real people, run this list:

No API keys, passwords, or tokens in the code. Rotate anything that was ever committed.
Every route that returns user data has a login and permission check.
Storage, databases, and buckets are private by default.
Dependencies are up to date, with no known-vulnerable versions.
Error messages do not leak stack traces, config, or secrets.

That covers the large majority of real incidents in fast-built apps.

If you want it done for you

You do not have to eyeball all of this. An independent scan can run the whole checklist and hand you the exact fixes, so you can ship with confidence instead of a nagging worry. That is the problem we built RepoFortify to solve, and it plugs into Claude Code, Cursor, and Windsurf so the fixes show up right where you are already working. But even if you never use a tool, the checklist above will catch most of what matters.

Ship fast. Just do the 15-minute check first.

https://repofortify.com/mcp?utm_source=devto&utm_medium=content&utm_campaign=vibe-security

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.