Check an AI-built app before you buy or launch
Evaluate an AI-built app by checking the rights, the delivered source, and the work required to run it yourself. A convincing demo answers part of the question. You also need to know which services the software depends on, who controls those accounts, and what you'll pay after purchase.
If you're buying a head start for your own software or for client work, keep a record of what you've verified. Separate what you can establish before payment from what requires source access. An unanswered question belongs in the budget and the buying decision.
What can you verify before buying?
Before paying, inspect the demo or walkthrough, read the license, and ask for the setup requirements and known limitations. Where source is delivered after payment, a clean deployment is still unverified until you have that source. Ask for evidence beforehand and decide whether the remaining uncertainty is acceptable. Keep the review in 3 stages: before payment, once source is available, and before launch.
| Stage | Evidence to collect |
|---|---|
| Before payment | License terms, demo behavior, included files, required accounts, deployment instructions, limitations, support scope |
| Once source is available | Version or bundle identifier, readable setup instructions, dependency lockfile, configuration inventory, results from running your own copy |
| Before launch | Access-control checks, failure handling, backup recovery, an operating budget, and a named person responsible for maintenance |
Save the software description and the Builder's answers with your review notes. Write each important claim as an observable result: “a submitted form creates a saved record,” rather than “forms work.”
What are you licensed to do with the code?
Read the actual rights before planning how you'll use the software. A source-code license, copyright ownership, and access to a hosted app give you different things. GitHub's licensing guidance also explains that publicly visible code without a license doesn't automatically grant permission to reproduce, distribute, or modify it.
On Zero to Hundred, you receive a non-exclusive, worldwide, perpetual license to use, modify, and deploy the software. The same software can be licensed to other Buyers. You may not resell, re-list, sub-license, or redistribute the software as a product. Read the license terms before paying.
Ask for the licenses and notices covering dependencies, fonts, images, and bundled templates. Record anything excluded from the purchase. If agency work requires handing source code to a client, settle the client's licensing needs before you buy. Don't assume a license for your own use covers that handover.
Does the demo represent the source you'll receive?
Ask which source version powers the demo, which screens use sample data, and which features need outside services. A deployed interface can conceal setup work that your copy still needs.
Pick the workflow you intend to use. Create a record, refresh the page, sign out, and return. Check whether the record persists. For an email feature, establish whether a message reaches an inbox or only appears in a preview. Use synthetic data and the Builder's permitted demo flows.
Code portability needs its own check. Lovable's deployment documentation separates application code from the backend, AI services, and connectors that may need reconfiguration or replacement when moving hosting. Exported code is one part of running the same software elsewhere.
Request a short inventory: what runs in the browser, what runs on a server, where data lives, and what calls an external service. Ask which parts are included in the source bundle. This is the detail to gather after checking whether the software you need already exists.
Can you configure it without the Builder's secrets?
You need documented configuration and credentials issued under accounts you control. Ask for a sample configuration file containing variable names and placeholders, plus instructions for creating the required services. Don't ask the Builder to send production credentials.
For each required value, record its purpose, whether it's public or private, where to create it, and whether it must be present at build time or runtime. Include callback URLs, webhook endpoints, storage permissions, and scheduled jobs. A missing callback setting can break sign-in even when the homepage loads.
Check browser-visible configuration separately. In Next.js, statically referenced NEXT_PUBLIC_ values can be included in browser JavaScript at build time. The Next.js environment guide explains that boundary. Keep private credentials out of those values.
Once you have source access, check for exposed credentials, including repository history if supplied. GitHub's secret-scanning documentation describes scanning Git history and rotating leaked credentials. Deleting a key from the latest file doesn't revoke it. Record whether your delivery includes history or only a snapshot, because that limits what you can inspect.
Which checks matter before launch?
Test the behavior your users will depend on in an isolated copy you control, using synthetic records and payment-provider test mode where relevant. Read the setup and install scripts before running unfamiliar source. Keep production credentials and real user data out of this first run.
Use this checklist as a starting point. Add the failures specific to your software.
| Check | Expected result | Evidence to keep |
|---|---|---|
| Main workflow | The intended action completes and survives a reload | Inputs, output, and the saved record |
| Signed-out access | Protected data and actions remain inaccessible | Response from a protected page and its underlying request |
| Separation between users | A second ordinary account can't read or change the first account's private record | Denied read and write attempts using synthetic records |
| Failed outside service | A timeout or rejected request produces an understandable failure without false success | Error response and a log entry without secrets |
| Repeated action | Retrying an action doesn't duplicate an order, charge, or entitlement | Final state after the repeat |
| Costly action | The configured usage limit actually blocks excess requests | A small, controlled check against your own copy |
| Data recovery | A backup restores usable records into a separate destination | Restore steps and a read-back check |
Authorization deserves more than a hidden button. The authorization guidance from the Open Worldwide Application Security Project calls for checking permissions on every request. Test the request as well as the screen.
For payment integrations, verify event handling too. Stripe documents duplicate webhook deliveries, so replay a test event and confirm it doesn't grant the same purchase twice. Check failed payment, cancellation, and refund behavior against the app's stated rules.
Review dependencies alongside behavior. Ask for pinned versions, a lockfile, runtime requirements, and known vulnerabilities. Use the appropriate dependency audit with its data-sharing behavior understood: npm's audit command submits dependency information to the configured registry to check known vulnerabilities. Its result doesn't establish whether your own permission checks or business rules are correct.
Can you deploy a fresh copy under your own accounts?
A useful deployment check starts from the delivered source and written instructions, with accounts and data you control. Record any missing step. Include schema setup, storage rules, sign-in callbacks, email configuration, scheduled jobs, and external-service settings that apply to the software.
After deployment, run the main workflow again on the deployed URL. Check that failures reach a log someone will read. Document how to revert an application change and how database changes affect recovery. A previous application version may need a compatible database state to work.
Ask what help comes with the purchase: installation assistance, updates, bug fixes, response times, and any support end date. Treat undocumented support as an open question. If another person will maintain the software, have them read the handover before you commit to a launch date.
What will the software cost after purchase?
Price the software around a unit of use you can measure, such as a completed report or an uploaded file. Include the services behind that action and the work needed to keep it running. A one-time source-code price doesn't establish a monthly operating cost.
| Cost area | What to establish |
|---|---|
| Hosting | Required runtime, requests, compute, bandwidth, build usage, and plan eligibility |
| Database and storage | Capacity, backups, reads and writes, file sizes, and data transfer |
| AI and external APIs | Calls per completed task, model or service used, retries, quotas, and failure behavior |
| Email and payments | Message volume, provider fees, and the account approvals your use requires |
| Maintenance | Updates, dependency fixes, monitoring, support work, and who pays for that time |
Vercel's pricing documentation, for example, separates charges for data transfer, requests, and compute duration. Check the current pricing and terms for every service this particular app requires.
Build a worksheet using your expected activity. Estimate a quiet month and a busier month, then record which inputs are measured and which are assumptions. Check whether each provider offers alerts or enforced limits, and what happens when a limit is reached. Don't count an alert as a spending cap.
When should you buy, wait, or walk away?
Buy when the rights fit your use, the demonstrated workflow fits your needs, and the remaining setup work has a responsible person and a budget. Wait when an important claim lacks evidence. Walk away when a required right is missing or a core dependency can't run under an arrangement you can use.
Keep the decision specific. “Email delivery needs configuration and a check” is work you can estimate. “Someone will fix production later” leaves the cost unresolved. A checklist records evidence and gaps; it can't certify security or guarantee that software fits every use.
How do these checks fit a Zero to Hundred purchase?
Use the public demo or walkthrough and the Builder's disclosures before payment. The marketplace shows software offered for source-code licensing. Source is delivered immediately after payment, so arrange your initial source checks in advance.
Every sale is final, with a 24-hour Report Window for misrepresentation, a bug that stops the software working, or other factual grounds. The Builder's payout is held for 72 hours. An upheld report is refunded from the held funds. Disclosed limitations aren't valid report grounds. Follow the purchase and report terms; the Report Window doesn't replace a technical review.
Browse Software, then use this checklist to decide what you still need to know before paying.
