DEV Community: Bogdan

I Have No Coding Skills. My Team Is 3 AI Models. Here’s the 100-Bug Audit That Saved My Second Startup.

Bogdan — Sun, 25 Oct 2026 19:26:09 +0000

Two weeks ago, I published the honest account of building ThumbRank with a team of three AI models and zero coding skills. The response was great — mainly because it wasn't a story about how AI writes perfect code. It was a story about how AI writes code that looks perfect until you try to charge money for it.

I didn't stop after ThumbRank. I pointed the same team at a much bigger problem: GrantPro AI.

It’s a funding intelligence platform. The core philosophy is simple: real numbers or guesses — there is no third option. Instead of asking an LLM to guess if you’ll win a grant, we ingest millions of public award records (USAspending, EU CORDIS, NIH, UKRI) and use deterministic code to calculate your real odds.

Same team structure as before:

AI #1: Writes features (React, Supabase, Edge Functions).

AI #2: Handles design and infrastructure.

AI #3: Exists for one reason: to audit everything the first two ship.

Me: The founder, PM, and QA department of one.

Month 1 looked like progress. We had a data pipeline, a dashboard, and a Paddle checkout.

Then I pointed AI #3 at the codebase before letting anyone pay.

It came back with ~100 unique bugs and 56 code-quality issues. Some of them would have destroyed the product on day one. Here are the ones that almost killed us, and how we fixed them.

The $0.00 Paddle Webhook Disaster The Bug: The AI configured the Paddle webhook to listen for price IDs. But it accidentally mapped two products to the same priceId. The Consequence: Users who bought the 1-credit pack received 5 credits. Users who bought the 5-credit pack received zero. The frontend showed "Success", the webhook returned 200 OK, but the database was silently dropping the money.

The Fix: We moved the idempotency check to the database level (Postgres unique index) instead of the application layer. If a webhook event arrives twice, or a mapping is wrong, the database throws an error and we log it.

sql
CREATE UNIQUE INDEX uq_credit_transactions_kind_reference
ON credit_transactions (kind, reference_id)
WHERE reference_id IS NOT NULL;

Client-Side Credit Spending (The "Free SaaS" Glitch) The Bug: The AI wrote the credit deduction in the React frontend. If the user had credits > 0, the UI let them click "Generate" and then called the Edge Function. The Consequence: Anyone who opened the browser console could bypass the UI and call the API directly. We were one curl command away from going bankrupt on OpenAI API costs.

The Fix: We deleted all client-side credit logic. Spending now happens exclusively via a Postgres SECURITY DEFINER RPC that checks the user's balance atomically on the server.

sql
CREATE OR REPLACE FUNCTION public.spend_credit(p_kind text)
RETURNS boolean LANGUAGE plpgsql SECURITY DEFINER AS $$
BEGIN
UPDATE credits SET balance = balance - 1
WHERE user_id = auth.uid() AND kind = p_kind AND balance > 0;
IF NOT FOUND THEN RETURN false; END IF;
RETURN true;
END; $$;

The Public Data Moat Leak The Bug: We spent a month ingesting 500,000 grant records into tables like awards and win_assessments. The AI enabled Row Level Security (RLS), but left the SELECT policy open to the anon role for caching purposes. The Consequence: Our entire proprietary Data Empire — the thing we built the company around — was fully readable by anyone with a Supabase anon key (which is public by design).

The Fix: We dropped the public read policies. If a table contains the "secret sauce" (historical awards, win probabilities), it is locked to service_role or authenticated users only.

The Zombie Function The Bug: The AI built an entire compliance checker. A beautiful UI, a complex prompt, and a Deno Edge Function. The Consequence: It literally didn't work. The AI forgot to export the handler (export default async function...). The function compiled, but when called by the frontend, it silently failed. It was a zombie feature.

The Fix: We added a CI gate that explicitly tests the exports of every Edge Function before deployment.

Why did the AI miss these?
Here is the hard truth about coding with LLMs: The AI is incredible at writing isolated files. It is terrible at understanding cross-file intersections.

AI #1 wrote the React checkout. AI #2 wrote the Paddle webhook. Neither of them knew that they needed to agree on how a user_id is passed. The bug lived in the gap between them.

The Rule We Build By Now
We didn't just fix the bugs. We changed the process.

The Invariants Doc: We wrote a document of cross-file rules. "Every paid checkout ends with credits on the right identity." "No public table is writable with the anon key." AI #1 reads this before coding. AI #3 reads this before auditing.

Regression-Testing the Auditor: We kept the old, buggy commit. Every time we update the auditor's prompt, we run it against the old code. If it doesn't find the 100 bugs again, the prompt got too soft, and we reject it.

What's Next?
GrantPro AI is live. We are tracking real grants across the US, EU, UK, Canada, and Japan.

If you are building with AI, remember this: The code the AI writes is only half the product. The other half is the system you build to catch it.

You can run a free win-check on your next grant proposal here: grantproai.com/win-check

I Have No Coding Skills. My Team Is 3 AI Models. Here's What We Built in 2 Months.

Bogdan — Tue, 06 Oct 2026 18:43:19 +0000

Two months ago I started building a SaaS with zero programming background. My whole team is 3 AI models and one human (me). This is the honest account — the features, the bugs only an AI could find, and the rule we now build by.

The setup

I'm a solo founder from Ukraine. No code background. Instead of learning to code first, I hired a team:

AI #1 writes features.
AI #2 handles design and infrastructure.
AI #3 exists for one purpose: auditing everything the first two ship.

I'm the founder, product manager, and QA department of one. We run three products (ThumbRank, GrantPro AI, DataEmpire) with two more in development.

The problem we solve

Every YouTube creator knows the math: a viewer scrolling search results spends about half a second on each thumbnail. If yours doesn't win that half-second, the video doesn't exist — no matter how good it is.

Yet almost everyone checks their thumbnail the wrong way: full screen, on a desktop monitor, alone. Not next to nine competitors. Not on a phone. Not in the actual place where the decision happens.

I spent three years growing a channel and made every mistake in that list. ThumbRank is the tool I wish existed.

What we built (stack: Next.js + Supabase + Vercel + Paddle)

SERP Radar — type any keyword, see the real top-9 YouTube results, every thumbnail scored for contrast, focus, and readability. Upload yours, get a verdict: clickable, or invisible.
AI Thumbnail Score — computer-vision grading in the browser (canvas + two-step downscale so JPEG noise doesn't move the score). Nothing is uploaded to a server.
Competitor tracking — follow up to 10 channels, get alerted when one swaps a thumbnail. A thumbnail swap is the most honest signal of what's working in a niche.
Channel X-ray — every week the system finds your three weakest thumbnails and writes a diagnosis for each.
Video Doctor — paste a link to any of your videos (even unlisted), get a full packaging report: title, thumbnail, hook, structure.
Morning digest — a daily email with new competitor videos and alerts. (Resend + verified domain, because emails that only reach the founder aren't a product.)

Month 1 looked like progress

180K+ previews rendered. Features shipping daily. A launch plan, affiliate links, the whole classic indie playbook.

Everything looked fine.

Everything was not fine.

Month 2: the audit

Before letting anyone pay, I pointed AI #3 at the codebase the other two had written. It read 124 files and came back with 14 bugs. Four were critical — and every one was invisible from the outside:

The payment webhook returned 401 for days. Root cause: the signature header format (t=...;h1=...) wasn't parsed correctly, and after rotating the secret every live event failed — while the dashboard politely showed "Active". My own subscription was broken and I didn't know it.
A cron job had never run once. Silently. Since the day it was created. The schedule existed, the code existed, the trigger didn't.
A wrong price ID sat under a correct-looking button. A real customer would have paid $49 for the $79 plan and received the wrong thing, with no error message anywhere.
Two ID systems. profiles.id ≠ auth.users.id — rows were linked to the wrong identity in half the app. Took a SQL migration (auth_user_id backfill via email) to converge.

The fix pattern that emerged: store webhook events first, dedupe by event ID, retry failures, and never trust a green dashboard. The dashboards were green the entire time.

The rule we now build by

Fix first. Sell second.

Then, because trust in a fix is not proof, I ran a real $20 charge through my own checkout. A fire drill, not revenue. The webhook fired, the plan flipped, the badge updated. Zero real customers so far — but the first one can't break what we already broke ourselves.

What's next

More honest numbers, posted publicly. The Product Hunt launch. The first real sale when it happens — and the reasons why it took as long as it did.

If you're building with AI as your team: the code it writes is only half the product. The other half is what you build to catch it.

Building ThumbRank in public. Free preview, no signup: thumbrankpro.com