DEV Community: Janni Hares

12 things to check before you ship your vibe-coded app

Janni Hares — Sat, 25 Jul 2026 15:16:54 +0000

Getting an app to work has stopped being the hard part. You describe what you want, Lovable or Bolt or v0 builds it, and forty minutes later there's something on a real URL that real people can click.

The hard part moved. It's now everything between "it works" and "it survives contact with the internet."

That gap isn't a vibe. It's measurable. Symbiotic Security crawled 65,643 URLs and fully scanned 1,072 Supabase-backed vibe-coded apps in June 2026: 98% had at least one security issue, 16% had something critical. A separate academic study by Deng et al. found that vibe-coded apps show recurring vulnerability patterns that differ from the ones traditional codebases produce — meaning these aren't random mistakes, they're structural. And an Xint.io analysis reported by SecurityWeek turned up 434 exploitable flaws concentrated in secrets exposure, broken authorization and denial of service.

Same handful of failure modes, over and over. Which is good news, because it means you can check for them in about fifteen minutes.

Below is the list I actually walk through. Everything here you can run against your own domain with curl and browser devtools. No tooling required.

1. Is your `.env` reachable over HTTP?

The single most common catastrophic finding. It happens when the build output directory and the project root end up being the same thing.

curl -sI https://yourapp.com/.env | head -1
curl -sI https://yourapp.com/.env.local | head -1
curl -sI https://yourapp.com/.env.production | head -1

Anything other than 404 is an emergency. Rotate every key in that file before you do anything else — assume it's already been scraped, because bots hit these paths constantly.

2. Is your `.git` directory exposed?

Worse than .env, because it hands over your entire history including keys you thought you'd removed.

curl -sI https://yourapp.com/.git/HEAD | head -1
curl -s  https://yourapp.com/.git/config

If HEAD returns 200, the whole repository is reconstructable by a stranger.

3. Which keys are sitting in your client bundle?

Open devtools, go to Sources, and search across all files. You're looking for sk-, service_role, SECRET, PRIVATE_KEY, and long strings starting with eyJ (those are JWTs).

The nuance that trips people up: a Supabase anon key in the browser is fine by design. A service_role key is not — it bypasses row-level security entirely. AI assistants confuse the two constantly, because both are "the Supabase key" from the prompt's point of view.

4. Is row-level security actually on?

Having an anon key in the browser is only safe if RLS is enabled on every table. Default-off is the trap. Go through your tables one by one and confirm policies exist. "I'll add policies later" is how the 16% happens.

5. Security headers

curl -sI https://yourapp.com | grep -iE 'content-security-policy|strict-transport-security|x-frame-options|x-content-type-options|referrer-policy|permissions-policy'

Most vibe-coded deploys return none of these. The two that matter most immediately are Content-Security-Policy (or at minimum frame-ancestors) to stop clickjacking, and Strict-Transport-Security so a downgrade attack can't strip your TLS.

6. Published source maps

curl -sI https://yourapp.com/_next/static/chunks/main.js.map | head -1

Source maps in production hand attackers your original, readable source — comments, internal function names, dead code paths and all. Turn them off in your build config, or restrict them to authenticated access.

7. Debug leftovers and orphan routes

Grep your own bundle for console.log and check whether anything sensitive is being printed on page load. Then try the routes nobody meant to ship: /api/debug, /api/test, /admin, /api/seed. AI-generated scaffolding loves to leave these behind, unauthenticated.

8. Rate limiting on auth and API endpoints

Almost never present unless explicitly asked for. Without it, your login endpoint is a free credential-stuffing target and your LLM-backed API route is somebody else's free inference budget. Check whether your host gives you rate limiting at the edge — often it's a config flag you just haven't flipped.

9. Error messages that leak

Trigger a failure deliberately: malformed JSON to a POST endpoint, a bad ID in a path parameter. If you get back a stack trace, a file path, or an ORM error naming your tables and columns, that's free reconnaissance for anyone probing you.

10. Untouched boilerplate

curl -s https://yourapp.com | grep -iE '<title>|og:image|og:description'

If it still says "Create Next App", or there's no Open Graph image, you're broadcasting that nobody reviewed this. It's not a vulnerability, but it changes how everything else about your product gets judged — including by the security researcher deciding whether you're worth poking at.

11. Trackers firing before consent

Open the Network tab, hard-reload, and watch what leaves the page before you've clicked anything. If Google Analytics, Meta Pixel or a session recorder fires on load, you have a consent problem in the EU — and a "we didn't know it was there" problem generally, because AI-generated templates ship with analytics snippets baked in.

Related and easy to miss: Google Fonts loaded at runtime from Google's CDN transmits visitor IP addresses to a third country. A German court ruled on exactly this in 2022 and it kicked off a wave of warning letters. Self-host your fonts. It's faster anyway.

12. Imprint and privacy policy

If you have users in Germany or Austria, an imprint is a legal requirement, not a nice-to-have, and the privacy policy has to actually describe what you're collecting. This is the check that costs nothing and gets skipped the most, because it's boring and nobody's prompt asked for it.

The fifteen-minute version

DOMAIN="https://yourapp.com"

for path in /.env /.env.local /.env.production /.git/HEAD /.git/config \
            /api/debug /api/test /admin; do
  code=$(curl -s -o /dev/null -w "%{http_code}" "$DOMAIN$path")
  echo "$code  $path"
done

echo "--- headers ---"
curl -sI "$DOMAIN" | grep -iE 'content-security-policy|strict-transport-security|x-frame-options|x-content-type-options|referrer-policy'

Every 200 in that first block is a finding. Every missing header in the second block is a gap. Run it against your own domain only — this is a self-audit, not a scanner to point at other people's sites.

What to do with the results

Sort into three buckets and be honest about which one you're in.

Exposed secrets, an open .git, or a service_role key in the bundle means stop. Rotate keys, fix, redeploy, and don't announce anything until it's clean.

Missing headers, source maps, debug routes and boilerplate metadata mean iterate — real issues, fixable in an afternoon, not reasons to delay a soft launch to a small audience.

Everything clean means go, with the caveat that this is a point-in-time snapshot. The next AI-generated feature can reintroduce any of it, so re-run before each meaningful deploy.

Disclosure: I work at decivo, where we do exactly this kind of review for teams shipping AI-built products. We wrapped the outside-in portion of this checklist into a free scan called Vibe Code Rescue — you paste a URL, it runs the external checks and gives you a Go / Iterate / Stop verdict. No signup, no code access, nothing stored. The manual checklist above covers the same ground if you'd rather do it yourself, which is genuinely fine by me.

We Stopped Writing Code First. Here's Why Our Projects Got Better.

Janni Hares — Mon, 13 Apr 2026 20:44:12 +0000

There's a moment in every project where you realize you've been building the wrong thing.

For us, it happened on a client project last year. Three weeks of clean code. Solid architecture. Tests passing. Then we showed it to actual users and watched them struggle with the core flow we thought was intuitive.

We didn't have a code problem. We had a clarity problem.

The pattern we kept seeing

We're a lean software studio. We build prototypes and MVPs for startups and companies. And the pattern was always the same:
Client comes in with an idea. Idea sounds great in a meeting. Everyone's excited. We start coding. Weeks later, something feels off. Users don't behave the way we expected. Features that seemed essential get ignored. The thing nobody asked for turns out to be the thing everyone actually needs.

Sound familiar?

What we changed

We stopped starting with code.
Not permanently. We still write code every day. But we stopped making it the first thing we do.

Now, before we open an editor, we do three things:

A clickable prototype that feels real Not wireframes. Not sketches on a napkin. A Figma prototype that looks and feels like a real product. No backend, no database – but real enough that when you put it in front of someone, they try to use it.

This takes us 2-3 days. It used to take weeks. AI tools like Figma Make help, but the key insight isn't the tooling – it's that a prototype answers questions a meeting never will.

Five conversations we don't want to have We put the prototype in front of 5-8 people from the target audience. Not friends. Not the client's team. Actual potential users. And we don't ask "do you like it?" – that's a useless question. Everyone says yes.

We ask: "Show me how you'd do X." Then we shut up and watch.
Where do they hesitate? Where do they tap the wrong thing? Where do they say "wait, what does this do?"
Every moment of confusion is a feature we would have built wrong.

Actively looking for reasons it won't work This is the counterintuitive one. We go into user conversations looking for the "no." "I would never use this because..." "This doesn't solve my actual problem because..." "I already handle this with a spreadsheet and it's fine." One honest "no" is worth more than ten polite "sounds interesting." What happens after

Only after these three steps do we write code. And by then, something has shifted:

The feature list is shorter (usually 40-50% shorter than the original spec)
The core flow is different from what everyone assumed in the kickoff
The client has seen real user reactions, not just our opinion
We know why we're building each feature, not just what

The numbers behind this

This isn't just our experience. CB Insights analyzed hundreds of startup post-mortems and found that 42% failed because there was no market need. Not bad code. Not running out of money. Building something nobody wanted.

The Startup Genome Project found that premature scaling – building too much before validating – kills 70% of startups. Teams that scale prematurely have 20x lower growth rates.

Think about that: the biggest risk isn't writing bad code. It's writing good code for the wrong thing.

"But we don't have time for validation"

This is the objection we hear most. And it's backwards.

You don't have time to not validate.

Two weeks of prototyping and user testing costs a fraction of what six months of building the wrong product costs. We've seen this play out multiple times: a client comes in wanting to build Feature X, we prototype it, test it, and discover that users actually need Feature Y. The prototype cost days. Building the wrong feature would have cost months.

How AI changes this (and how it doesn't)

We use AI heavily. Claude Code writes our implementations. Figma Make generates design drafts. Gemini handles competitive research. AI is involved in 6 of our 12 workflow phases.

But here's what AI doesn't do: it doesn't tell you whether you're solving the right problem.

AI makes building faster. That's genuinely useful. But if your direction is wrong, AI just gets you to the wrong destination more efficiently. The code will be clean. The architecture will be solid. And the product will still miss.

That's why every AI step in our workflow has a human gate after it. AI proposes, humans decide. Not because AI is bad – because speed without direction is waste.

The uncomfortable truth

Most of the value we deliver to clients isn't code. It's the moment in a user test when someone says "I don't need this" and saves the client from building it.

That moment is uncomfortable. Nobody wants to hear that their idea needs changing. But it's infinitely cheaper to hear it from a prototype test than from an empty dashboard after launch.
If you're about to start building something – a side project, a client project, a startup – try this before you write your first line of code:

Build a clickable prototype (Figma, even just screenshots stitched together)
Put it in front of 5 people who have the problem you're solving
Ask them to use it, not whether they like it
Listen for the "no"

It might save you months.

We're the team of decivo. We build prototypes and MVPs for startups – with an AI-powered validated workflow