Testing an AI-built quote form: validation, mobile labels and unsupported claims

Partner disclosure: MeDo provided LaunchWise with 500 testing credits at no charge. LaunchWise participates in its affiliate program. The linked LaunchWise review contains affiliate links; we may earn a commission on qualifying purchases. AI disclosure: ChatGPT generated the text of this article from our test record and screenshots, with no human line editing. The prototype tests were carried out by the LaunchWise owner with ChatGPT assistance.

A generated website can look finished before its form and copy have been checked. We used MeDo to build a small quote-request prototype, then tested the result before publishing it. This reports one demo, not production readiness or a benchmark of AI app builders.

1. Start with testable acceptance criteria

Our fictional web design studio was called LaunchWise. We requested an English-language page in navy, white and turquoise, with:

• Required name, email and project description fields.
• Website type, estimated budget and an optional launch date.
• Email-format validation and an on-screen confirmation.
• A visible “Demo only — use sample data” notice.

The brief explicitly requested no login, no stored submissions, no outgoing emails and no external service connections. A small scope made comparison with the brief easier.

2. Test failures before a successful submission

Submitting an empty form was blocked. Inline errors identified the missing name, email and description.

With a name and description entered, we tried hibasemail. The form rejected it with an email-format error.

We then submitted fictional data:

• Name: Test User
• Email: [email protected]
• Description: This is a demo test for a small business website.

A confirmation displayed the submitted details. These observations establish that those specific visible paths worked in our test. They do not establish server-side validation, exhaustive email validation or security.

3. Check narrow layouts with realistic selections

At a 390px-wide mobile preview, the form stacked vertically, but long website-type and budget selections were clipped. This is easy to miss if a screenshot contains only empty fields.

We requested shorter labels with the same meaning. “Corporate & Business Website” became “Corporate & Business”; budget options used currency ranges without lengthy parenthetical descriptions.

In the revised preview, the selected labels we checked were readable. Submitting the sample data again produced a confirmation showing the expected name, email, budget and description. This was a browser-preview check, not a physical-phone test across multiple devices.

4. Review generated claims as carefully as the UI

The first version included a promise of tailored proposals within 24 hours and a “Core Web Vitals 95+” claim. We had not established either claim.

We asked for the turnaround promise to be replaced with a demo explanation and the numerical performance claim to be removed. The revision used “Optimized performance” instead. That wording is not evidence of measured performance: we did not run a performance benchmark.

For each generated sentence, ask: did we request it, test it, or have evidence for it? Plausible marketing copy needs review too.

5. Verify publication and explain the demo boundary

We published the revised demo and checked that its public page loaded outside the editor. It includes demo notices and a simulated confirmation flow.

You can try the public demo using fictional sample data only. LaunchWise in the demo is a fictional web design studio; submitting the form is not a request for a real quote.

Our brief requested no storage or email sending, and the interface describes that behaviour. We did not independently audit the backend or network traffic, so this article does not certify the absence of those operations.

A checklist you can reuse

1. Define acceptance criteria before generating the page.
2. Submit empty required fields.
3. Try a clearly invalid email format.
4. Submit fictional valid data and inspect the confirmation.
5. Check long selected labels at a narrow viewport.
6. Remove unsupported promises and numerical claims.
7. Repeat the important checks after a revision.
8. Open the published page outside the editor.
9. State which checks you did not perform.

We also did not complete a full accessibility audit, security review or production workflow test. Our takeaway from this small experiment is that useful prototypes still need deliberate checking of both interactions and words.

The LaunchWise hands-on review includes screenshots, the brief and test results. That review contains affiliate links.

What additional failure case would you add to this checklist?