How We Test AI App Builders

By the PrototypeVerdict Test Team · Last updated: October 29, 2026 · Most recent test round: Oct 29, 2026

We may earn a commission if you buy through links on this page. How we make money.

Every AI app builder we review gets the same job: build the same three small apps from the same three prompts, pasted word for word. We write down what we sent, how long it took, what it used up, what broke and whether the fixes worked. Then we check the results ourselves before anything goes into a review.

This page explains exactly what we do, what we haven’t tested yet, and how we keep pages up to date.

---

The short version

1. Same three prompts in every tool. A client intake portal, an invoice tracker and a one-page landing page. One initial prompt each, pasted verbatim.
2. At most 5 fix messages per build. We only send a follow-up message if something is broken.
3. We log time and usage. Minutes to a first preview, minutes to “working,” and the credits, messages or tokens used, read from the tool’s own balance before and after.
4. We check who can see what. For the client portal, we sign in as a separate, non-admin client account and confirm it can’t reach the admin view.
5. We check phone width. Every build gets desktop and phone-width screenshots.
6. We check code export. We note whether the tool offers a code download or GitHub connection.
7. Fake data and test accounts only. Nothing we build in a test is published.

---

The three test builds

We paste these prompts into every tool exactly as written below. We don’t reword them for a particular tool, and we don’t add hints. If a tool asks a clarifying question or stops partway, we note it.

Build 1: Client intake portal

This tests sign-up and login, a form, file uploads, per-user data and an admin role, which is where AI-built apps most often go wrong.

Build a client intake portal for a small accounting firm. Clients can sign up and log in with email and password. After logging in, a client fills out an intake form (full name, business name, entity type dropdown: Sole proprietor / LLC / S corp / C corp / Partnership, tax year, a notes field) and uploads up to 3 documents (PDF or image). Clients can see their own past submissions and their status. A separate admin view lists all submissions in a table with a status dropdown (New, In review, Complete) that the admin can change. Clean, professional design that works on mobile.

Build 2: Invoice tracker

This tests a working database, automatic calculations, date-based logic and whether data survives a page refresh.

Build an invoice tracker for a freelancer. I can add clients (name, email) and create invoices with an invoice number, client, issue date, due date, line items (description, quantity, rate), and an automatic total. Each invoice has a status: Draft, Sent, Paid, Overdue (Overdue is automatic when the due date has passed and it isn’t paid). A dashboard shows total outstanding, total paid this month, and a list of overdue invoices. Data must be saved so it’s still there after a page refresh. Works on mobile.

Build 3: LedgerLight landing page

This tests design, layout on a phone, and whether a simple contact form actually saves what visitors send. LedgerLight is a made-up business.

Build a one-page marketing landing page for a fictional bookkeeping service called “LedgerLight” for small businesses. Include a hero with headline and call-to-action button, three feature blocks, a three-tier pricing table ($49, $99, $199 per month), three testimonials clearly labeled as sample placeholders, an FAQ with five questions, and a contact form that saves submissions. Fast, modern, mobile-friendly.

---

The rules for every build

Who runs the tests. AI agents ran our test sessions in real accounts with each tool, using our fixed prompts word for word: paid Lovable Pro and Base44 Builder plans that we bought, and Bolt’s free plan. Every result was logged, including times, usage and the exact text of every follow-up message, and every result was reviewed before it went into a page.

One prompt, then fixes only if something is broken. Each build starts with the prompt above and nothing else. If a listed feature doesn’t work, we can send a short follow-up message describing the problem, and we log the exact text of each one.

A limit of 5 fix messages per build. After 5 fix messages we stop, and the review reports whatever still doesn’t work. In our Oct 29, 2026 round, no build needed more than 1.

Every follow-up counts. We count every message we send after the first prompt, even when it isn’t strictly a bug fix. For example, when one tool paused at a checkpoint during the invoice tracker build, our one-word “continue” reply went into the log as a fix message.

Same feature checklist for everyone. We mark each feature in the prompt pass or fail, note what broke and whether the fix worked.

Fake data only. We use invented names, invented businesses and test accounts. We don’t put real client information into a test app, and we suggest you don’t either until you’ve reviewed the tool’s security settings.

Nothing gets published. Test projects stay in the tool’s editor or preview. We don’t publish them to a public address.

---

What we record for every build

Each tool has its own test log. For every build, the log records:

• The date, the plan we used and the exact follow-up messages we sent.
• Usage: the credits, messages or tokens used, taken from the balance the tool shows before and after the build. Each tool counts usage differently (Lovable in credits, Base44 in message and integration credits, Bolt in tokens), so we report each in its own unit.
• Time: minutes to the first working preview, and minutes until every listed feature worked.
• Feature checklist: pass or fail for each item in the prompt, plus what broke and whether the fix worked.
• Backend and data: whether sign-in, the database and file uploads actually kept their data. We refresh or reload the page to check.
• Code ownership: whether the tool offers a code download, a GitHub connection or a publish option.
• Screenshots: desktop and phone width.

When a tool’s numbers don’t agree, we say so. In our Lovable test, the balance went from 105 to 99.5 credits across the three builds, but Lovable’s usage page showed about 10.2 credits for the same projects (it appears to include the 5 free daily build credits). We report the balance figures and point out the gap. See the Lovable review for the full breakdown.

Times are approximate. We write “about” wherever a time wasn’t measured to the second.

---

Extra checks after the first build

Client vs admin access, with a separate account

A client portal is only useful if clients can’t see each other’s data or reach the admin view. So for the client intake portal, we sign up a second, separate client account that isn’t an admin and check three things:

1. Does it see an Admin link?
2. What happens when it goes straight to the admin page?
3. Does it see only its own submissions?

Results so far (rechecked Oct 29, 2026):

One more thing we record: whether the tool gives you a built-in way to create the first admin. In our test, neither Lovable nor Bolt did. Lovable needed one extra message, and in Bolt we set the admin role by hand in its database. Details are in Bolt vs Lovable.

Phone-width screenshots

All three prompts ask for a design that works on mobile, so we take phone-width screenshots of every build. We use each tool’s own phone preview where it has one, or the browser’s device mode:

• Base44: its phone preview, about 373 pixels wide.
• Bolt: its iPhone-size preview, 402 × 874.
• Lovable: the browser’s device mode at 400 pixels wide. Our first Lovable captures were about 840 pixels wide, which is too wide to count as a phone, so we retook them on Oct 29, 2026.

Before any screenshot goes on the site, we crop it to the app and remove test account details such as email addresses.

Code export

We check whether each tool lets you take your code with you, and we say exactly how far we got:

Finding an export button isn’t the same as having a project that runs somewhere else. For example, Base44’s own documentation says exported code still depends on Base44’s backend. We cover that in the Base44 review.

---

What we haven’t tested yet

We’d rather say what we haven’t checked than imply we have. As of our Oct 29, 2026 round, these were still open:

• The separate client account check on Bolt.
• The prompt’s 3-document upload limit. Our logs don’t record a check of it for any tool.
• Exporting data to CSV in Bolt. Its free plan had run out of tokens (done for Lovable and Base44).
• Running any tool’s exported code outside its platform, and connecting GitHub in Base44 and Bolt.
• Bolt’s security tools. Its docs describe a project security audit and a database security check, but we didn’t find or run them.
• How fast Base44’s integration credits drain when an app uses a real integration such as email.
• Paid Bolt plans. Bolt was tested on its free plan only.

When a review depends on something we haven’t tested, the review says so.

---

Our first test round (Oct 29, 2026)

We ran all three builds in three tools on Oct 29, 2026, each on the plan shown below. Full results are in each review and comparison.

“Working” means every feature in the prompt that we checked passed. One build can be “working” and still have a catch we think you should know about. For example, Lovable’s invoice tracker passed the refresh test but saved its data in the browser only, not in a database. Base44 saved all three apps’ data in a real database. That difference is a big part of Base44 vs Lovable.

For a quick way to choose between these tools, start on our homepage.

---

How we score

Each tool gets a score built from five weighted parts:

Our scale: each part gets a score from 0 to 10, in half points. The overall score is the weighted average of the five parts, shown out of 10 and rounded to one decimal. Every part starts at 10, and we take points off only for specific things recorded in our test log:

Scores from our Oct 29, 2026 round:

The three overall scores are within half a point of each other, which we treat as close, so read the parts and each page’s “pick if” advice. Each review explains its scores.

Two things we don’t score yet:

• Dependency warnings from a tool’s security scan. Lovable’s dependencies panel listed 12 known issues, and Base44’s scan flagged 7 high-severity ones. We didn’t run a Bolt scan. We report these on each page but don’t take points off, because we couldn’t compare them on equal terms.
• Anything we couldn’t test. Bolt’s CSV export wasn’t tested (its free plan had run out of tokens), and neither was Bolt’s separate client account check. Bolt’s code ownership score doesn’t include CSV, and its backend score loses a point for the missing account check.

What we never do: we don’t show star ratings collected from other sites or an “average” rating, and a tool can’t pay to change its score. How we make money is explained in our affiliate disclosure.

---

How often we recheck prices

AI app builder prices and plans change often, so every review shows two dates: “Last tested” and “Pricing checked.”

• When we write or update a page, we check prices against the tool’s own pricing page or documentation and link the source.
• Every month, we recheck the prices of every tool we’ve reviewed.
• When a price or plan changes, we update the affected pages and note the change in each page’s update history.

Prices on our pages are in US dollars and dated. Always confirm the price on the tool’s own site before you buy.

---

How we update pages

• Freshness reviews. We review every review, comparison and best-of page if it hasn’t had a substantive update in 90 days, and every other page after 180 days.
• Real changes only. We change a page’s “Last updated” date only when we’ve actually changed something, such as new prices, new screenshots, new test results or a corrected fact.
• Retests. We rerun the three standard builds in every tool we cover once a quarter, and sooner when a tool ships a major release.
• Corrections. If you spot a mistake, email us at contact@prototypeverdict.com. When we correct a fact, we fix it on the page and add a dated note saying what changed.
• Update history. Every page ends with a dated “Update history” section listing what we changed and when.

Our editorial policy covers corrections and our no-paid-placements rule in more detail.

Spotted something out of date or wrong? Tell us at contact@prototypeverdict.com.

---

How We Test FAQ

Do you use the same prompt in every tool?

Yes. We paste the same three prompts, word for word, into every tool we test: a client intake portal, an invoice tracker and a landing page. The full prompts are on this page.

How many times do you let a tool fix its own mistakes?

Up to 5 follow-up messages per build, and only when something is broken. We log the exact text of every follow-up. In our Oct 29, 2026 round, no build needed more than 1.

Do tools that pay you get tested differently?

No. Every tool gets the same three builds, the same rules and the same checks, whether or not it has an affiliate program.

Do you test with real client data?

No. We use fake names, fake businesses and test accounts only, and nothing we build in a test is published.

---

Related tests

• Lovable review: 3 apps built on the Pro plan
• Base44 review: 3 apps built on the Builder plan
• Base44 vs Lovable: the same 3 apps in both

Update history

• October 29, 2026: First published. Describes our Oct 29, 2026 test round and the scoring scale.