When a website looks finished, but isn't
VibeCheck is a self-initiated audit tool. Not client work, not a portfolio exercise, just something I built on my own time because I kept catching the same problem across AI-assisted builds, including my own: a site can look completely done and still be quietly broken underneath. I scoped it, designed it, and built it, and I'm now in the final stretch of getting it ready for other people to use.
Vibe coding tools can take an idea to a polished-looking site in minutes. But "looks done" and "is production-ready" are different claims, and the gap between them, missing site icons, incomplete SMTP, broken functionality, accessibility issues, poor performance, SEO & GEO gaps, usually stays invisible until someone hits it.
Sole designer and builder. I decided what was actually worth auditing, designed how a non-auditor should read the results, and built the working product end to end.
- Ran manual audits across a handful of AI-built sites, mine and others', to find the failure patterns that kept repeating, then turned that into the product's five audit categories.
- Designed the report around one decision: a single score and a short, ranked list of critical issues up top, not a wall of raw findings.
- Built the audit engine and dashboard myself, using Playwright to actually load and interact with the target site rather than only parsing its markup.
A working tool, now in final QA ahead of opening it up, that I already run against my own builds before I call anything done, catching the specific class of issue a visual review alone would miss.
The "score plus a short critical list" framing came directly from watching the first version fail: a raw findings dump just made the problem feel bigger, nobody acted on it.
I didn't set out to build an audit tool
This started as a personal habit, not a product idea. I use AI tools daily to move fast on prototypes and side projects, and I kept noticing the same thing: a site would look complete, ship-ready even, right up until I actually poked at it. A contact form silently failing because SMTP was never wired up. A missing favicon. Content that rendered fine to my eyes but would confuse a screen reader. None of these show up when you're evaluating a build the way most people evaluate a build, by looking at it.
Evidence: manual audits across my own and others' AI-built sitesI only trusted this was a real pattern, not a one-off mistake, after running the same manual check across a handful of different AI-built sites and getting the same category of failure back every time. The specific bug changed, the shape of it didn't.
Every AI-assisted build front-loads the visible layer and leaves the unglamorous, unseen layer, the part that actually determines whether real users and search engines can use the thing, as an afterthought. Looking at a site was never going to catch that, because the whole point is that it looks fine.
What I chose to prioritize, and what I left out
The interesting part of this project wasn't running the audits, it was deciding what to do with what they found. A raw checklist of everything technically wrong with a site is overwhelming and, in practice, useless to the person who actually needs to act on it.
Score plus a short critical list, not an exhaustive report. Everything else lives behind a details view instead of the front screen, because the first version's full report just made people close the tab.
Five categories, not fifteen. SEO, performance, security, accessibility, and integrations were the repeat offenders across every manual audit I ran. I deliberately left out things like code-quality linting, that's a developer's concern, not the one this tool is answering.
Real browser checks over static parsing. Playwright actually loads and interacts with the page, which is slower and harder to build than scanning source markup, but it's the only way to catch what a real visitor's browser would actually hit.
Tested this on the first three people who tried the tool. Nobody read past the first screen, more data made the problem feel bigger, not clearer.
Matches how someone actually decides what to fix first: is this launch-blocking, or not. Everything else can wait for the details view.
Built, tested, and getting ready to open up
VibeCheck runs a real audit against a URL and returns a score, a category breakdown, and a prioritized list of critical issues, the kind that would actually block a launch if left unfixed. It's a working product, not a mockup, and it's already part of how I close out my own builds before I call something done. It hasn't opened up publicly yet, I'm using this final stretch to tighten the parts only real usage tends to surface.
A quick note on this one. VibeCheck hasn't launched publicly yet, so there's no external adoption data to cite here. What's above describes what's been built and the decisions behind it, not metrics from a live product.