Key takeaways:
- I built 11 free GTM diagnostic tools at sandsdx.com/lab/ using AI-assisted coding, with zero prior experience writing React or TypeScript
- Ninety days of analytics then made the uncomfortable case: five tools had zero runs, and the portfolio was diluting its own best work. I killed six.
- The five survivors were rebuilt to a higher bar: real agent pipelines with visible stages, and verification passes that re-check every key finding before reporting it
- The process took weeks of iteration, not the “build an app in 20 minutes” you see on Twitter. It’s real work. It’s just a different kind of work.
- The constraint has shifted from “can we build this?” to “do we know what to build, and what to stop maintaining?”
The problem I was trying to solve
I run a fractional GTM practice for B2B SaaS companies. My site needed to do two things: explain what I do, and prove I can actually do it.
The “explain” part is straightforward. A homepage, a services page, some written perspectives. Standard stuff.
The “prove” part is harder. Every consultant has a website that says they’re strategic and experienced. Nobody reads those pages and thinks “yes, this person clearly knows what they’re doing.” They think “this person has a website.”
I wanted something different. I wanted people to interact with my thinking before they ever talk to me. Run their homepage through a diagnostic. See their positioning gaps mapped out. See the vendor shortlist AI hands their buyers.
Free tools. Real analysis. Useful output.
The catch: I’m not a developer. I’ve never shipped a React component. I can read code well enough to follow along, but writing a TypeScript application from scratch was not in my skill set.
What “vibe coding” actually looks like in practice
The term gets thrown around a lot, usually alongside a screen recording of someone building a to-do app in 90 seconds. That’s misleading.
I started with the Hero Checker. The concept was simple: paste a URL, scrape the hero section, and run it through Claude’s API with a detailed scoring rubric. Five categories, five points each, 25-point scale. Specific criteria for each score level so the analysis would be consistent and useful.
The scoring rubric was the easy part. I’ve audited hundreds of B2B homepages. I know what separates a clear hero section from a vague one. Translating that into a structured prompt took maybe an hour.
Building the actual tool took considerably longer.
I described what I wanted to Claude Code: a React component with a URL input, a loading state, an API route that scrapes the page and sends the content to Claude, and a results display with scores and recommendations. Claude Code scaffolded the whole thing. First version worked on the third try.
“Worked” is generous. It scraped pages inconsistently. The loading state was janky. The results layout looked like a homework assignment. The error handling was nonexistent.
This is the part the Twitter demos skip. The first output gets you maybe 60% of the way there. The next 40% is where all the real time goes.
I spent days iterating. “Move the score cards into a grid.” “Handle the case where the scraper can’t find a hero section.” “Rate limit to five scans per day per user.” Each prompt got me closer. Each one also occasionally broke something that was working before.
Building the portfolio
After the Hero Checker, I had a rough mental model: paste input, hit an API, display structured results. The pattern repeated, and the roster grew. A structured data detector. A competitor analyzer with a 60-point framework. A citation tracker checking whether AI assistants mention your brand. A buying committee analyzer. A brand narrative checker. A positioning differentiator. A messaging drift analyzer. Eventually a category strategy tool run by four sequenced agents, and the two AI-visibility tools that became the heart of the lab.
Eleven tools, each between two days and a week of focused iteration. The AI analysis prompts were the most important part. Getting Claude to produce consistent, specific, actionable output required detailed system prompts with explicit scoring criteria and examples. I rewrote those prompts dozens of times. The prompts are the product. The React components are just the delivery mechanism.
Shipping felt like the achievement. It wasn’t.
What the data said
Ninety days after the portfolio was live, I read the analytics the way I’d read a client’s.
Roughly 40 visitors across all lab pages in a quarter. Five tools with zero analysis runs. Three CTA clicks total, and all three came from the two AI-visibility tools. The most-used tool, the Hero Checker, had 15 runs. Several tools I’d spent a week each building had never been run by anyone but me.
That’s not a story about bad tools. Most of them worked fine. It’s a story about dilution. Eleven tools on an index page means a visitor evaluates eleven options and picks none. The tools that mapped to what I actually sell earned attention; the ones that existed because I could build them just added noise around the signal.
I’d have told a client this in the first meeting. It took me a quarter to tell myself.
Killing six
So I ran the exercise I run on client tech stacks. Score each tool on three axes: does it feed the business (my engagement ladder), does the data show use, and how much friction does it ask of the visitor?
Six failed. The citation tracker and buying committee analyzer were partial copies of the visibility baseline, so they merged into it. The competitor analyzer, positioning differentiator, and brand narrative checker folded conceptually into the category strategy tool. The messaging drift analyzer became a client deliverable instead of a free tool, which is what it always should have been.
Every retired URL got a redirect to the tool that absorbed its job. The dead components and API routes came out of the codebase entirely, which also closed off unused endpoints that could call an LLM on my dime.
The lesson I’d offer any team doing this: when shipping is cheap, portfolio discipline replaces shipping as the scarce skill. A published tool is a claim on visitor attention and a statement about your method. Eleven claims meant none of them landed.
The rebuild: tools that verify their own claims
Killing six funded the more important move: raising the bar on the five that stayed.
In my client work, no finding ships without a citation, and important findings get checked twice. The tools now hold themselves to the same standard. The shortlist tool asks the buyer’s question, then a verification agent asks it again in different words and compares the two runs; vendors that survive both get marked as stable, and ones that appear once get flagged. The visibility baseline re-asks every absence before reporting it, because an absence is the finding a buyer acts on. The Hero Checker scores twice and reports the spread, so a 23/25 comes with “stable within ±1” instead of false precision.
The progress bars are real now too. Each stage of each tool advances when that agent’s work actually completes, and you can watch the committee get mapped, the questions get asked, and the verification run. The earlier versions faked that with timers. For a business whose whole pitch is agent-informed delivery with evidence behind every claim, simulated agent progress was the one thing the site could not contain.
What I actually learned
Domain expertise is the bottleneck, not coding ability. The hardest part was never the code. It was knowing what a good competitive analysis measures, or which buying committee roles matter. AI can write a React component. It cannot tell you what a B2B positioning audit should measure.
Prompts are products. Each tool’s value lives almost entirely in the system prompt that drives the analysis. That’s where the time went, and where it should have gone.
You will break things constantly. AI coding tools work on what you show them. I learned to describe changes carefully: “Update the loading state. Don’t change the API response format or any other component.” Being explicit about what should stay the same is as important as describing what should change.
The architecture decisions are yours. I caught the AI storing rate-limit data in a way that wouldn’t persist across serverless functions, and once making a client-side call that would have exposed an API key. These are thinking problems, not coding problems.
Measure, or you’re guessing. The portfolio looked successful right up until I read a quarter of analytics like an outsider. Instrument the tools from day one, and schedule the honest read.
Ship small, then iterate. Then prune. Launching the Hero Checker first validated the pattern before I built more. What I’d add now: put a review date on everything you ship. The kill decision was worth more than three of the builds.
What this can’t do
These tools run on serverless infrastructure and handle real traffic, but they’re not software built by a team of engineers. There’s no test suite. Error handling covers the common cases. Rate limiting runs both client-side and per-route on the server now, which stops casual abuse; it wouldn’t survive someone determined. For free diagnostics, that trade-off is fine. For a paid product, you’d need real infrastructure.
The AI analysis has limits too. Claude is good at structured evaluation against a rubric, but it works from scraped text. It can’t see your visual design or tell you whether your site “feels” trustworthy. The verification passes make the findings honest. They don’t make them comprehensive.
What this means for other GTM teams
The lab does what I built it for. People find the tools, run their sites through them, see the quality of the analysis, and some reach out. A prospect who has watched the shortlist tool map their absence from an AI answer already understands what I do. The sales conversation starts in a different place.
The bigger point is about what’s now possible for any B2B marketing team. If you have an interactive tool that would help your buyers and it’s sitting in an engineering backlog, you can build a functional version this week. The constraint has shifted. It used to be: can we build this? Now it’s two questions: do we know what to build, and do we have the discipline to kill what isn’t working?
Both of those are GTM questions, not engineering questions. The code is the easy part. The thinking is the hard part.
It always was.