I built VerrixAI solo over about a month. It is a tool that takes a contract or lease, runs it through Claude, and gives you back a plain-English breakdown with risk flags. I am not a lawyer. I wanted something I could hand to my parents when they ask me what their lease actually says.

This post is the honest version. The parts I got wrong, the bugs that took days to find, the security audit I almost forgot to do, and the numbers behind the unit economics. It is long because the interesting stuff is in the details.

What the product actually does

You drop in a PDF, DOCX, or TXT file, or paste text. The document content is extracted in your browser using pdf.js and JSZip. Only the extracted text is sent to the server, capped at 60,000 characters. The original file never leaves the browser.

The server passes the text to Claude with a tight system prompt and gets back four things:

1. A short summary of what the document is
2. Risk flags graded HIGH, MEDIUM, or LOW with a short explanation each
3. The obligations and clauses worth knowing about
4. A plain-language rewrite

There is a hard cap of 8 risks per response, with a carveout that all HIGH-severity risks are always included up to a ceiling of 15. Anything dropped is counted in a separate field so the UI can say "3 lower-severity risks omitted."

The stack

Plain HTML, CSS, and JS. No framework. Six static HTML files.

Vercel for hosting, edge functions, and cron. Supabase for auth and Postgres. Anthropic Claude Sonnet 4.6 for the analysis itself. Stripe for subscriptions. Resend for transactional email. Hostinger for the domain and DNS.

Seven API endpoints under /api/: analyse, create-checkout, change-plan, cancel-subscription, stripe-webhook, delete-account, and a "want to know more" form handler.

I made the no-framework choice deliberately. Frameworks are great when there is a team. For a solo build where I needed to ship a thing rather than learn a thing, plain HTML let me move faster and debug in DevTools
without source maps.

The cost math

This is the part that matters most for the unit economics.

A typical scan sends about 470 tokens of system prompt plus up to about 15,000 input tokens from the user document, and gets back up to 4,000 output tokens. At Sonnet 4.6 pricing that works out to roughly A$0.07 per scan in worst case, less for shorter documents.

Plans are:

• Free: 3 scans total
• Starter: A$5/month for 50 scans/month
• Pro: A$9/month for 100 scans/month
• Pro 2: A$15/month for 250 scans/month

Margin is comfortable on every paid tier even at 100 percent quota usage. The Free tier is a real cost (about A$0.21 per free user worst case) and I accepted that because it is the only way I would have tried the product myself.

I considered scan top-ups for heavy Pro 2 users approaching the margin cliff but parked it as a post-launch feature. Pre-launch I had no data on whether anyone would actually hit the quota.

Vibe coding with Claude

I built most of this by talking to Claude. I gave it the spec, asked for components, pushed back when the code was wrong, and shipped what worked. I have a network admin background so I can read code and break it intelligently, but I am not a frontend developer.

What that actually felt like in practice was not "Claude wrote the app." It was more like having a very fast pair programmer who occasionally generates plausible nonsense, and your job is to be the person who notices.

The places where I had to be the noticing person:

Claude does not know what it does not know. Several times Claude generated code calling APIs that did not exist, or with parameter names that were almost right but off by one word. The fix is to test everything end to end before assuming it works. I caught these because I deployed to a Vercel preview branch and clicked through every flow. The bug usually surfaced within five minutes.

Claude pattern-matches to the most common solution, not the right one. When I asked for a payment integration, the first draft used sub.current_period_end. That field moved in the Stripe API version 2025-03-31 update. The new path is sub.items.data[0].current_period_end. Claude knew about both but defaulted to the old one. Every Stripe read in the app now uses a fallback chain.

Claude will happily silence errors. Several try/catch blocks in early drafts were swallowing real failures. I had to be deliberate about logging and about where failures should propagate versus where they should be caught.

The cumulative point is: AI-assisted coding works, but only if you treat the output as a first draft and not a delivery. The work is in the testing and the noticing, not in the typing.

Bugs and war stories

The navigator.locks deadlock

This one took me three sessions to fully understand. Supabase JS client uses a navigator.locks based mechanism for serialising calls in the same tab. On certain async patterns, the HTTP call would complete (network tab showed 200 OK), but the JS promise wrapper would never resolve. The await sat there forever.

I hit this six times across different code paths. The pattern that emerged:

1. Wrap any critical Supabase JS call in a race against a timeout
2. On timeout, read the access token from localStorage and call the REST API directly via fetch

For state transitions like sign-in and sign-out, the cleanest workaround was a full page reload after the auth event. That re-initialises the Supabase JS client from scratch and clears whatever was wedged.

The cause is a known issue with Supabase JS 2.39 and above. I am pinned to 2.38.4 because of it. Anthropic told me the same thing in a different conversation. Specifically:

npm install @supabase/supabase-js@2.38.4

Not 2.38.x, not @latest, exactly 2.38.4. Upgrading silently breaks sessions on a subset of browsers and you will not see it in dev.

The sign-out token still being valid

Related to the deadlock work. When you call signOut, Supabase JS clears its in-memory state and the cookie, but the sb-{projectref}-auth-token key in localStorage can survive long enough for the next page load to read it and silently sign the user back in.

The fix is:

// Clear sb-* localStorage keys BEFORE redirect or reload
Object.keys(localStorage)
  .filter(k => k.startsWith('sb-'))
  .forEach(k => localStorage.removeItem(k));
window.location.href = '/';

If you do not clear before the redirect, the next page boots up, reads the still-valid token, and the user is signed in again. This bit me twice before I worked out what was happening.

Quota drift across surfaces

The original quotas were Free 5, Pro 300, Pro 2 700. I changed them to 3, 50, 100, 250 after the cost analysis.

I did not appreciate how many surfaces reference quotas until I started looking. Stale numbers were in:

• The Supabase confirm-signup email template
• The launch invite HTML
• knowmore.js (the "want to know more" form's pricing list)
• account.html cancellation modal copy
• account.html upgrade nudges
• terms.html Section 5 plan listings
• Two hardcoded 5 defaults inside account.html itself (one in HTML, one as a JS fallback)

It took three separate sweep passes to catch them all. The lesson: every customer-facing surface that mentions a quota number is a candidate for drift. When quotas change in code, you have to manually sweep all of them. There is no compiler that catches "the email template still says 5 scans."

Webhook idempotency, before I had it

Stripe retries webhook events on any non-2xx response. My first webhook handler had no idempotency check at all. The handler was idempotent in some places but not others. Specifically: on customer.subscription.updated, I was resetting scans_used to 0 to handle the monthly billing cycle reset. A retried event would re-run that handler, resetting scans to 0 again mid-month, giving the user free scans they had not paid for.

The fix is a small table:

create table public.processed_webhook_events (
  event_id text primary key,
  event_type text not null,
  processed_at timestamptz not null default now()
);

alter table public.processed_webhook_events enable row level security;
create policy "deny_all_webhook_events" on public.processed_webhook_events
  for all to public using (false);

The webhook inserts the event_id at the start of processing. PostgREST returns 409 on the primary key conflict, which is the signal to return 200 immediately without re-running anything. Insert before processing, not after, so a crashed handler does not leave the door open for retries to do damage.

The security audit I almost forgot

A week before launch I did a full pass through the code looking for vulnerabilities. I found one launch blocker and three defensive issues.

The launch blocker. The /api/delete-account endpoint was deleting the Supabase user and the profile row, but doing nothing with the Stripe subscription. A paying customer who clicked "delete my account" would have had their account vanish from the app while continuing to be billed every month forever. They would only find out by checking their card statement, by which point it is a chargeback. That bug had been in production for weeks before launch. It would have been visible the first time a real paid customer deleted their account.

The fix was 15 lines. Fetch stripe_subscription_id from the profile before deleting it, call DELETE /v1/subscriptions/{id} with cancellation_details metadata for Stripe analytics, then proceed with the existing deletion. Cancel-immediately, no refund. The deletion confirmation modal now explicitly says "Your subscription will be cancelled immediately."

The deeper lesson: code reviews catch syntactic bugs. Architectural bugs need someone to ask "what happens when a paid user deletes their account" out loud. I did not ask that question for a month.

Constant-time HMAC compare. My Stripe webhook signature verification was using !== to compare the computed and expected HMACs. That is a timing side channel. In practice, hard to exploit over the public internet because network jitter dominates the timing difference. In principle, you use crypto.timingSafeEqual from node:crypto because it is the right answer and your future security auditor will not flag it. Three line fix.

Prompt injection boundary enforcement. My code wrapped user document content in --- DOCUMENT START --- / --- DOCUMENT END --- boundary markers, with a comment claiming this defended against prompt injection. It did, except for the case where the user's document itself contained the literal string --- DOCUMENT END --- followed by an instruction. The fix is one regex:

const safeContent = rawContent.replace(
  /\s*-{2,}\s*DOCUMENT\s+(START|END)\s*-{2,}\s*/gi,
  ' [boundary marker removed] '
);

I tested it with 14 attack variants and 6 benign cases. All passed. As a bonus, when I tried a manual injection through the live product after deploying, the model identified the injection attempt itself and flagged it as "Possible Document Tampering or Fraud" with HIGH severity. Defence in depth working as intended.

Things I did not build, by choice

No admin panel. Every operation an admin would need can be done in Supabase Studio with SQL. Building an admin UI is a long tail of buttons, permission edge cases, and one more place for credentials to leak. I am not building it until I genuinely need it.

No real-time anything. No WebSockets, no Server-Sent Events, no subscriptions on the Supabase client. The product does not need it and every realtime feature is another deadlock candidate.

No SSR, no React, no Next.js. Plain HTML works. Adding a framework would have added two weeks of "learn the framework" plus ongoing version churn.

No mobile app. The web version is responsive. Mobile app is a post-traction decision.

What is on the post-launch list

Things I deliberately punted on:

• Self-service subscription reactivation (currently you have to email me)
• DMARC policy ramp from p=none to p=quarantine to p=reject
• Prompt caching (my system prompt is below the 1,024 token Sonnet minimum so caching does nothing)
• Replacing the frontend profile creation with a Supabase DB trigger (closes the USER_LIMIT DevTools tampering loophole)
• Dunning handler for invoice.payment_failed

Each one is in the master doc with an explicit reason it can wait. The pattern I followed: if it is not a launch blocker, and the workaround is reasonable, document it and ship.

Numbers and reflections

Time spent: about a month of evenings and weekends. I have a day job as a network admin.

Stack cost pre-launch: under A$50 total. Vercel Pro for previews and cron. Supabase free tier. Resend free tier. Stripe takes its cut on transactions. Anthropic API usage on my own testing was about A$8.

Per-scan AI cost: ~A$0.07 worst case. Per-scan profit on Starter at 100 percent quota usage: A$1.50. On Pro 2: A$8.50.

Lines of code: about 6,600 across HTML, CSS, and JS in the main app, plus 1,500 in the seven API endpoints.

Things I would tell anyone considering a similar build:

1. Use AI assistance, but do not trust it. Test everything end to end before you assume it works.
2. The architecture decisions you make on day one will haunt you. Pick boring technology that you can debug at 2am.
3. Whatever your auth provider is, expect to fight it. Mine took six instances of working around a deadlock pattern.
4. Do the security audit before you launch, not after. There will be at least one bug you would lose sleep over if a paying customer found it first.
5. Write down every decision and every workaround as you make it. By month two you will not remember why you pinned that exact version, and the cost of figuring it out again is high.

VerrixAI is live at verrixai.com. The free tier does not need a card. I am still polishing for the Product Hunt launch.

Feedback welcome, especially on the risk-flag output and anything that reads wrong for non-Australian contracts. I am most curious whether the plain-language rewrites are actually useful or whether they over-simplify the original document.