The limits of AI for building a web product

Coding assistants changed the cost of a first version. An interface, forms, a database, a deployment: a well-guided agent produces all of it in a few hours. What has not changed is the distance between code that renders and a product customers can rely on. This article goes task by task through what AI does well, what needs evidence, and the minimum evidence to get before you depend on the result.

Producing is not proving

A coding agent produces code. It can also produce tests, explanations and a message saying “everything works”. None of these is evidence of real behaviour. Evidence is a test observed under the conditions that matter: two different accounts, a declined card, a notification delivered twice, a backup actually restored. Until someone has observed it, it is an assumption — sometimes right, sometimes not.

So the limit is not only the quality of the generated code. It is what a demo does not show: failure cases, access between users, what happens at 2 a.m. when a third-party service stops answering. These points can be checked; they cannot be guessed by looking at the screen.

Task by task

The table follows the order in which a web product gets built. The last column describes the simplest evidence that changes a decision: if it fails, you do not launch — or you launch less.

Access rights: where a demo shows nothing

A demo runs on one account. An access defect — a customer seeing another customer’s invoices — only shows with two. With Supabase, protection rests on Row Level Security (RLS): according to Supabase’s documentation, once RLS is enabled no data is reachable through the API with the publishable key until a policy allows it; conversely, a secret key bypasses those policies and must never end up in the browser. An agent can write these policies correctly. It can also write one that is too broad, or forget a table. Only the two-account test settles it — including when calling the API directly rather than through the interface.

Payments: the thank-you page proves nothing

Stripe’s documentation on order fulfilment is clear on two points. First, you cannot rely on the post-payment landing page alone: nothing guarantees the customer loads it, and the notification sent to your server (the webhook) is required. Second, fulfilment can be called several times for the same payment, sometimes concurrently: it must give the same result every time. Some payment methods also confirm the payment only later. An agent knows these rules; the only way to know whether your code follows them is to replay the notification and count the access grants.

Tests: who checks the checker?

When the same tool writes the code and its tests, the tests tend to describe what the code already does, mistakes included. A useful test fails when the business rule is broken. The check is simple: break a rule on purpose — let an unpaid account through, for instance — and see whether a test turns red. If it stays green, it protects nothing.

Site copy: volume is not effort

AI writes quickly and cleanly. Google’s guidance on helpful content notes that using generative AI to produce lots of text without human review or curation represents little to no effort, and that content should be made for people first. For a product, that means verified claims, an identifiable author, and nothing you could not defend if a customer asked.

When a specialist review is worth it

A review by an experienced person costs time and money. It pays off when a mistake would cost more:

• Real personal data, and all the more so sensitive data: health, personal finances, identity documents, minors, records covered by professional secrecy.
• Several customer companies in the same product, each isolated, with its own roles.
• Money that moves in more than a simple payment: usage-based billing, payouts to third parties, credits, partial refunds.
• Irreversible actions: transfers, bulk sends, deletions, automated decisions that affect people.
• An outage that loses sales or breaks a commitment to customers.
• Nobody named to fix things after launch.

To frame what gets checked, OWASP’s ASVS standard (version 5.0.0, released in May 2025) lists the security requirements of a web application. It is a useful reference; ticking a list inspired by it does not make a product “compliant” or “certified”.

When it is useless

Conversely, paying for a review is often unnecessary:

• A prototype with fictional data, shown to a few people to test an idea.
• A tool only you use, holding nobody else’s data.
• A brochure site with no accounts and no payments, made with an established site builder.
• An automation between existing tools that moves information those tools already protect.
• A need an existing product already covers: buying and configuring it often beats building, and there is then no code of yours to review.

In these situations, the best investment is your time: talking to users, testing demand, keeping the scope small.

A working rule

For every point that matters — access, payments, recovery — write down what you know and how you know it. “Checked on 12 October, two accounts, refusal observed” is worth more than “the agent said it was fine”. What has not been checked is not necessarily wrong; it is unknown. And unknown is not low risk.

For the list of tests to run just before a launch, see what a founder should verify before launching an AI-built SaaS. For a complete decision example — what you build yourself, what you buy, what you have checked — see the SaaS MVP case.