41 agents, each with one job.

Maps a project before a launch check.

Takes the findings from all LaunchReadyKit checkers, removes duplicates and false alarms, runs the scoring script for the 0-100 launch score and verdict, and writes the launch report in plain language.

Finds leaked API keys, passwords and tokens in source code, public environment variables, config files and build output.

Searches a repository's git history for secrets and .env files that were committed in the past and can still be recovered, and checks whether the repository is public.

Reviews login, signup, sessions and password reset to find ways someone could reach private data without logging in or get into an account that is not theirs.

Checks that login, signup and costly endpoints limit how often they can be called, so nobody can guess passwords at speed or run up the owner's bill on paid services such as AI models, email and SMS.

Works out who is allowed to do what in an app, then finds where someone can reach another user's or another team's data, give themselves more rights, or use an admin function.

Checks that file uploads are limited by type and size, saved under safe names, and not readable by the wrong people.

Looks for places where user or AI-generated input can change a database query, run a command, read files, make the server fetch other addresses, or run scripts in other users' browsers.

Checks the security headers a site sends, which other websites may call its API (CORS), protection against forged requests, and debug information leaking in production.

Audits a project's packages for known security holes, fake or misspelled package names, missing lockfiles and outdated frameworks.

Reviews how an app talks to AI models, to find ways a user could make the AI ignore its instructions, act on other users' data, leak what it was told, or be used at the owner's expense.

Reviews a Supabase project's row-level security policies, views and database functions to find data that anyone on the internet can read or change.

Reviews Supabase Storage buckets and their access policies to find private files that are public and files that any user can overwrite or delete.

Reviews Firebase security rules for Firestore, Realtime Database and Storage, plus Admin SDK keys and Cloud Functions, to find data that anyone can read or change.

Reviews how a project connects to its SQL database and whether the schema has the basic safeguards: a limited-rights user, encryption, connection pooling, indexes and constraints.

Reviews how a project changes its database structure: whether migrations exist, whether a pending one would destroy data, whether seed scripts could reach production, and whether development and production share a database.

Checks whether users can delete their account and get a copy of their data, and whether deletion really removes their personal data from every table, from file storage and from outside services.

Finds database queries that will slow down or fail as data and traffic grow: queries in loops, lists with no limit, filtering in app code, deep OFFSET paging, wildcard search and missing timeouts.

Finds places where data goes wrong when two requests arrive at once or a step fails halfway: balances and stock that lose updates, missing transactions, coupons used twice, unsafe retries, deleted rows that reappear and cascades that delete too much.

Finds database setup that breaks under real traffic and real deploys: pooler settings that crash queries, connection pools larger than the database allows, migrations that lock busy tables, raw database errors shown to users, no recovery from brief outages and stale replica reads.

Reviews checkout, subscriptions, pricing and refunds to find ways customers could pay the wrong amount, get the product without paying, or keep access after a refund.

Reviews payment webhook handlers for missing signature verification, duplicate processing, unhandled events and silent failures that lose paid orders.

Finds places where the app's record of who has paid drifts from the payment provider over time: out-of-order webhook events, renewals that cannot be matched to a user, subscription statuses handled wrong, double billing, cancellations that cut access too early, no resync after a missed webhook and currency conversion mistakes.

Finds payment code that fails silently or twice under real conditions: charges and refunds that can be sent twice, provider list calls that read only the first page, unpinned API versions, no record of payment events, swallowed payment errors and card declines users cannot recover from.

Checks whether a project has the privacy policy, terms, refund policy, business details and AI disclosures it needs, and writes those pages from what the code really does.

Checks the practical privacy basics in the code: tracking before consent, marketing email consent, personal data sent to third parties or written to logs.

Checks the technical SEO basics a site needs to be found: titles and descriptions, sitemap, robots.txt, canonical addresses, link previews, not-found pages and broken links.

Checks a site's structured data (JSON-LD) for errors and invented claims, and writes correct Schema.org markup for the pages that benefit.

Checks whether AI answer engines such as ChatGPT, Claude, Perplexity and Google AI Overviews can crawl, read and accurately describe a site.

Finds what makes a site slow to load and slow to respond: heavy images, oversized JavaScript, render-blocking scripts, fonts and uncached pages.

Checks a site for common barriers to people using a keyboard, a screen reader or with low vision: missing labels, poor contrast, hidden focus, clickable divs and inaccessible pop-ups.

Checks that a site works on phones: viewport, layouts that fit narrow screens, tap targets, readable text and usable forms.

Checks whether errors are reported, handled and logged safely, and sets up an error tracking service when asked.

Checks whether the database and uploaded files are backed up, whether hosting plans could pause or drop the project, and whether anything alerts the owner when the site goes down.

Checks that a project is configured to run correctly in production: environment variables, build health, host limits, domain and callback addresses, and email delivery setup.

Finds code that turns a slow or failing service, a second server instance or a restart into an outage or lost work: outside calls with no timeout, background work that is silently dropped, retry storms, failed jobs that vanish, scheduled jobs that run twice, in-memory state on multi-instance hosts, no graceful shutdown and memory that grows without limit.

Finds what makes deploying a new version risky: shared caches that serve one user's page to another, database changes that break the running or previous version, open browser tabs that break after a deploy, live connections the host cuts, risky features with no off switch and no check after deploy.

Writes launch material in the maker's own voice: Product Hunt listing and first comment, X announcement and thread, Reddit posts per community, and a tailored launch-day checklist.

Reviews a landing page's words, structure and email capture as a first-time visitor would: is it clear what the product is, who it is for, why to trust it and what to do next.

Checks whether a site measures visits, signups and purchases, and sets up privacy-friendly analytics with the key events when asked.