https://shipreadyai.dev/launch-review > Discover all available pages from the documentation index at https://shipreadyai.dev/llms.txt # A person checks what a URL cannot show For founders putting real users on an AI-built app in the next 30 days. Alex reads the parts of your app the free check marks as not verified, gives each one a verdict with the evidence, ranks what to fix first, and records a walkthrough. You make the changes, or you make them together in a Hardening Sprint. Launch Review, $199 one-time. First reply within 1 business day. Delivered within 3 business days. Refundable in full any time before work starts. ## Who it is for - Your app signs people in, and one customer must never see another customer's data. - You take payments, or will within a month. - Real users arrive in the next 30 days, or they already have. - You built it with Lovable, Bolt, v0, Replit, Cursor, Claude Code, Codex or similar, and nobody with production experience has read it yet. Not for: - A weekend project with no users planned. The free check and the checklist generator cover that. - Someone who wants the changes made for them. That is the Hardening Sprint. ## What gets reviewed These are the items the free check lists as not verified. Your own check decides which of them apply to your app, from what it detected and what you told it. Each one gets a verdict, Verified or Needs fix, with the evidence behind it. An item the access shared cannot settle stays Not verified, with a note on what access would settle it. - Rollback and recovery: Whether you can put the previous version back, and how long that takes. - Error monitoring: Whether a failure in production reaches a human rather than sitting in a log nobody opens. - Sign in and account flows: Whether sign in, password or code reset, and session expiry behave under real use. - Rate limiting and abuse controls: Whether a script can hammer your forms, sign up loop, or paid endpoints without being slowed down. - Key rotation: Whether you can replace a leaked key quickly and know everywhere it is used. - Payment handling: Whether payment events are verified, replay safe, and matched to the right customer record. - Customer data handling: Whether stored personal details are limited, deletable on request, and out of your logs. - AI feature controls: Whether prompts, spend, and model output are bounded so one visitor cannot run up the bill. - Database row rules: Whether the row rules behind the app actually stop one signed in account reading another's rows. - Certificate expiry date: Whether the certificate is close to expiring. A normal request proves the certificate is valid right now, and the runtime this check uses cannot read the expiry date from that request. - One account reading another account's data: Whether a signed in account can reach another account's records by changing an id. ShipReady does not create accounts, sign in, or call your functions, so this cannot be answered from outside. - How fast the page is for a real visitor: Whether the first screen arrives quickly on a phone connection. This check reads the page once from a server, which says nothing about what a visitor on a train sees. - Colour contrast in the interface: Whether text and controls stay readable against their background, including muted text, placeholders, disabled buttons and focus outlines. - How the layout holds on a phone: Whether the layout actually works at phone width. A viewport tag allows the page to adapt; it does not prove anything fits. - Whether your forms refuse automated submissions: Whether a script can post your public forms repeatedly. Sending test traffic at your forms is not something an outside check should do uninvited. - Whether the cookie choice is honoured: Whether a banner appears where it is required, and whether declining actually stops anything being stored. - Whether the first screen asks for one thing: Whether a visitor arriving cold knows the single next step. That is a judgement about your product, not something a request can read. ## What you get - A written review: one verdict per item, the evidence behind it, what it would cost you if it failed, and how long the fix takes. - A ranked fix order, so the first hour goes to the item that matters most. - A fix prompt for your builder on every Needs fix item. - About 15 minutes of recorded walkthrough from Alex, following the same order. - Your Launch Risk Statement updated item by item, dated, with Alex's note. - Release Gate included, a $49 value. - The $199 credited toward a Hardening Sprint within 30 days. ## What is not included - No changes to your code. You or your builder apply the fix prompts. Having the fixes made with you is the Hardening Sprint. - No second reading after you fix things. That is Re-verification, $99, or part of a Hardening Sprint. The 30 day re-check reruns the free check. - Nothing is attacked and nothing is written to your data. Signed in checks use test accounts you create. ## A sample review A worked example for a fictional app, tallybook.example. It is not a customer and none of it is real evidence. Tallybook is a multi-user invoicing app built with Lovable, using Lovable Cloud for data and sign in and Stripe for subscriptions. Eight items applied. Two need fixing before launch, both under a day of work. Two more belong in the first week. Three were verified, and one stays not verified with the access shared. Recommendation: hold the launch until items 1 and 2 are fixed and re-checked. Items 3 and 4 can follow in the first week. 1. One account reading another account's data: Needs fix, Before launch. Evidence: Signed in as test account B, opening the address of an invoice that belongs to account A showed the full invoice. Signed out, the same address showed nothing. If it fails: Any customer can read any other customer's invoices by changing an id. That is a disclosure you would have to tell every customer about. Fix: Add a row rule on the invoices table that only lets an account read and change rows it owns, then repeat the request as account B and confirm it returns nothing. Under an hour. 2. Payment handling: Needs fix, Before launch. Evidence: In the repository, the subscription webhook grants the plan before checking the event signature, and nothing records which events were already handled. If it fails: Anyone who finds the webhook address could grant themselves a paid plan, and a retried event would run the grant a second time. Fix: Verify the Stripe signature before reading the event, store each event id once, and ignore an id you have already processed. Two to three hours. 3. Rate limiting and abuse controls: Needs fix, This week. Evidence: In the repository, the sign up handler sends a welcome email on every request and has no limit per address. Not tested with repeated sign ups, since that would send real email. If it fails: A script could use up your email sending quota and fill your user table with junk accounts in an afternoon. Fix: Limit sign ups per address and per email domain, and add a quiet bot trap field to the form. An afternoon. 4. Key rotation: Needs fix, This week. Evidence: The owner's settings screenshots show the Stripe secret key stored twice: once in the backend secrets and once in a scheduled job's settings. Nothing records where each key is used. If it fails: If the key leaks, rotating it breaks the scheduled job without warning, so a rotation becomes an outage. Fix: Keep the key in one place, have the job read it from there, and write down every key with where it lives. Under an hour. 5. Database row rules: Verified. Evidence: In the repository, row rules on customers, payments and settings each limit reads and writes to the owning account. As account B, the pages for account A's customers, payments and settings showed nothing. 6. Sign in and account flows: Verified. Evidence: Sign in, password reset and sign out behaved as expected for both test accounts. Opening a dashboard address signed out went to the sign in page. 7. Rollback and recovery: Verified. Evidence: On a shared screen, the owner restored the previous version from the builder's history in under two minutes. 8. Error monitoring: Not verified. Evidence: No monitoring access was shared, and the owner said none is set up. Left as Not verified rather than passed. Fix: Connect an error monitoring service and send one deliberate error to confirm an alert reaches you within five minutes. ## How it works 1. You check out and fill in a short intake, about four minutes. 2. Alex replies within 1 business day with anything he needs. 3. The written review plus the Loom arrive within 3 business days. 4. Your statement is updated item by item, dated, with Alex's note. 5. A re-check 30 days later shows you the cleared list. ## What Alex needs from you Required: - The published address of the app. - Your top concern, in a sentence. Optional: - A link to a public repository, or read access to a private one. - Two test accounts you create, so cross-account access can be checked by signing in as each. - Screenshots or exports of your database rules, payment settings, or deployment history. Never asked for: - Production passwords or your own account. - Secret keys, service role keys, or payment provider secret keys. - Write access to production data. ## How your data is handled - Your intake, the written review and the walkthrough link stay in your library so you can return to them. - Evidence is written as what was observed and where. Record ids and personal details are left out of the review. - Test accounts are used only for the review. Delete them once the review is delivered. - Check records are kept for 90 days and then deleted. You can ask for anything tied to your email to be deleted at any time, and the request is actioned within 30 days. ## Already ran a scanner? Good. Bring the result to the intake. Built-in scans and outside scanners read your code, your packages, your settings, or what a visitor can see. They are useful, and some of them go further than the free check here. What they leave open is whether your app behaves correctly for real users: whether account B can open account A's records, whether a replayed payment event grants access twice, whether you can roll back a bad release. If your scanner already answered an item, Alex records that and moves on. If the review turns up nothing you did not already know, you do not pay. ## Who reviews it Alex Cinovoj, founder and CTO of TechTide AI. 13 years in US enterprise IT, from help desk and hospital systems to MSP work and cloud engineering. Lovable Senior Champion, 9 Anthropic Academy course completions. Logs over Vibes — a new podcast from Alex Cinovoj and Shane Spencer. Coming soon. Season 1 aired as Automation Vibes (2025). Every review is written by him, not generated. ## Questions ### Does the Launch Review include fixing things? No. You get a verdict, the evidence and a fix prompt for every item, and you or your builder make the change. If you want the fixes made with you, that is the Hardening Sprint, $1,750, and the review price is credited toward it within 30 days. ### Does Alex try to break into my app? No. Nothing is attacked and nothing is written to your data. Signed in checks use the test accounts you create, the way a careful new customer would use the app. The payment path is walked up to the point of paying and stops before any charge. Repository reading is read only. ### Do you need my code? No. A repository makes some verdicts faster and firmer. Without one, Alex works from the live app, your test accounts and the evidence you share, and any item that cannot be answered that way stays Not verified instead of passed. ### What happens after I fix the Needs fix items? Rerun the free check at any time; the 30 day re-check is included. A person reading your fixes again and recording new verdicts is Re-verification, $99, or part of a Hardening Sprint. ### I run an agency. Can I share the review with my client? Yes. The written review and the statement are yours to forward to the client the app was built for. The client has to have agreed to the review first. ### Is this the same as other products called ShipReady? No. This ShipReady is at shipreadyai.dev, run by Alex Cinovoj of TechTide AI. Other products using the name on other domains are separate companies. ShipReady is not a penetration test or a security certification. No automated check can prove an application is secure.