For founder-built apps

From “works on my machine” to production-ready in ten business days.

You built it with Lovable, Base44, Replit, Bolt, Cursor or Claude Code. It mostly works. Then real users, a custom domain or Stripe in live mode broke something you can’t see. Ship-Check finds every one of those in 72 hours, in writing, and ships the worst one fixed as a pull request you can read.

Sound familiar?

The six ways a finished-looking app isn’t finished.

  • Users can see each other’s data

    Works perfectly for you because you created the rows. Row-level security was never turned on, or the policy says “true”.

  • Login works in preview, loops after publish

    Redirect URLs, cookie domains and the custom domain never got into the auth settings. Nobody told you.

  • Checkout works, subscriptions never update

    Stripe is still in test mode somewhere: keys, the webhook endpoint, or price IDs copied from the test dashboard.

  • Deploy fails again

    An environment variable set in preview but not production, or a refresh on /dashboard that 404s because nothing rewrites client routes.

  • 400 credits burned on the same bug

    The tool keeps saying it’s fixed. It isn’t. Every regeneration adds a second copy of the logic.

  • The person who built it disappeared

    A freelancer, an agency, or last month’s version of you. Nobody knows where the keys live.

How it works

Audit first. Fixed scope. Fixed price.

  1. 01

    A twenty-minute look

    Send the repo link or live URL and one sentence on what “done” looks like this week. You get a short written note: what is actually broken, what I would fix first, and what the audit would cost. No call needed.

    Free · one business day

  2. 02

    Ship-Check audit

    Twenty-five checks across secrets, auth and row-level security, data, payments, reliability, deploy and quality. You get a scored report, the fix list in order with hour ranges, a ten-minute video walkthrough, and the single highest-risk fix shipped as a pull request with a test.

    72 hours from access · read-only · fee credited to the sprint

  3. 03

    Rescue Sprint

    Every launch-blocking and user-breaking item from the audit, fixed on branches against a staging copy, delivered as pull requests you review before merge. CI, error alerts and a CLAUDE.md with the repo’s rules come with it, so your own next changes don’t re-break it.

    Ten business days · 14-day warranty

  4. 04

    Build-Partner

    Optional, afterwards: a monthly block of engineering hours, dependency and security updates, a 48-hour response window on US Eastern business days, and a recorded health report every month.

    Monthly · three-month minimum · exclusions in writing

The 25 checks

Run it yourself today. Or have me run it on your actual code.

Every item is scored 0, 1 or 2 and tagged by severity: launch-blocking, breaks under real users, or hygiene. Anything I can’t verify with the access you give is marked unknown, never guessed.

Secrets and configuration

  1. 01

    No secrets in the client bundle or git history

    Anything prefixed VITE_ or NEXT_PUBLIC_ ships to the browser. A service-role or live Stripe key there is launch-blocking and must be rotated.

  2. 02

    Separate dev and production keys

    Different Supabase projects or keys, a .env.example that lists every variable, no .env committed.

  3. 03

    Config documented

    Someone other than you can find where each variable is set in the host.

Auth and access

  1. 04

    Row-level security on every table with user data

    A user table without RLS is the single most common launch-blocker in generated apps.

  2. 05

    Policies tested for cross-user access

    A two-user test proves user A cannot read or change B’s rows. “using (true)” on a user table fails this.

  3. 06

    Admin actions gated on the server

    A client-side isAdmin flag is not a gate.

  4. 07

    Auth works on the live domain

    Redirect URLs, site URL and cookie domain match production; no localhost left in the code.

  5. 08

    Password reset and email flows point at production

    Templates, sender and links use the live domain.

Data

  1. 09

    Migrations tracked and reproducible

    Schema changes live in version control, not only in a dashboard.

  2. 10

    Backups or point-in-time recovery

    A plan tier with PITR, or at least a scheduled dump that someone has restored once.

  3. 11

    Schema integrity

    Foreign keys, unique constraints on emails and slugs, indexes on the columns your lists filter by.

Payments

  1. 12

    Live keys and a live, signature-verified webhook

    The webhook endpoint exists in live mode and the handler checks Stripe’s signature.

  2. 13

    Idempotent fulfilment and subscription sync

    Repeated events are ignored; cancellations and failed payments change what the user can do; entitlement is read from the database, not a client flag.

  3. 14

    Tax, refunds, cancellation and the customer portal

    A billing portal link exists and the tax setting is a decision, not an accident.

Reliability

  1. 15

    Error handling and logging

    No empty catch blocks; server errors logged with context; users see a message, not a blank screen.

  2. 16

    Error alerting

    Sentry or an equivalent, wired for server and client, with you notified.

  3. 17

    Health check and uptime monitor

    An external monitor tells you before a customer does.

  4. 18

    Rate limiting on public endpoints

    Forms, auth and anything that sends email or calls a paid API cannot be hammered anonymously.

Deploy

  1. 19

    Reproducible build and CI

    A clean clone builds; typecheck, lint and tests run on every pull request.

  2. 20

    Hosting configuration

    Env vars in the host, custom domain and SSL, www/apex redirect, client-routing rewrites, security headers.

  3. 21

    Staging and rollback

    A preview environment exists and someone knows how to roll back.

Quality

  1. 22

    Tests on the money paths

    At least one automated test each for sign-in, the core flow and payment fulfilment.

  2. 23

    Dependency audit

    Known vulnerabilities fixed, and every package actually exists; generated code sometimes imports packages that don’t.

  3. 24

    Performance basics

    No fetch loops in list views, images sized, bundle under control, main page loads in about three seconds on mobile.

  4. 25

    Ownership and docs

    A README, a CLAUDE.md or equivalent with the repo’s rules, dead code removed, a one-page runbook.

Fit check

This is for you if

  • You built the app yourself with Lovable, Base44, Replit, Bolt, Cursor, v0 or Claude Code, or inherited one.
  • There are real users, paying customers or a launch date, and something has broken that you can’t see.
  • You want fixes you can read and merge yourself, on your own repo, with tests that prove them.
  • You would rather pay once for a fixed scope than by the hour for a surprise.

Not a fit

  • Healthcare, medical or clinical products.
  • Salesforce or CRM implementation work.
  • Hourly bids, ground-up rewrites, or new features before the fixes.
  • Hobby projects with no users and no launch date. Run the checklist above instead; it is free.

Before you pay

Things you can check first.

The audit is read-only

You grant read access to the repo. The one fix ships on a branch as a pull request; nothing is merged or deployed by me, and production data, DNS and live payment settings are never touched without your written OK.

Your exposure is one audit, not a project

The audit is fixed-price and told to you before you pay. If you take the sprint within two weeks, the audit fee is credited in full.

The intake you are about to use is our own system

The form below posts into the same lead pipeline FlowForge runs for its own enquiries: it logs the request, alerts a human, and sends you an acknowledgement. Claim-what-runs is the house rule.

What it costs

Fixed price, told to you before you pay.

The twenty-minute look is free and ends in a written note with the number in it. Nothing is due before you have seen what is broken.

The audit is one fixed fee, prepaid, credited to the sprint if you book within fourteen days. The sprint is one fixed fee for the fix list in the report, half to start and half on acceptance, with a fourteen-day warranty. Anything outside the list is a written change order you approve first.

Questions

Asked before the first message.

Start here

Send the repo. Get a written note within one business day.

What is actually broken, what I would fix first, and what the audit would cost. Then you decide.

Prefer email? hello@bettercallflowforge.qd.je

Read-only look · no passwords, ever · no newsletter

Ship-Check and the Rescue Sprint are delivered by FlowForge, US-run, on US Eastern business hours. Read-only audit; fixes as reviewed pull requests; you keep every line of code, every account and every document.