Building a SaaS with AI: what's missing before you charge customers

Building a SaaS with AI works very well for validating an idea: in a few days, a prompt-based tool delivers login, a database, and screens that work. What it does not guarantee is who sees whose data. Before the first paying customer, you still need to check database authorization, exposed keys, backups, and the legal duty when something leaks.

The Portuguese-language guides that teach you to build a SaaS without coding stop at publishing: the most complete one, updated in June 2026, sums up security in half a sentence, and another, from March, gets to the first paying customer without touching the subject. This article covers the stretch between the prototype and the path of a SaaS after validation.

Wama created ManyFeed, its own social proof SaaS built with AI in the process, so there is no sermon against the tool here. The point is different: generated code passes the "it works" test long before it passes the "it protects" test.

How far does building a SaaS with AI go?

It works up to the moment the product starts storing someone else's data. To test flow, price, and interest, a prompt-generated prototype is a cheap and fast way to put something clickable in front of people who would buy.

The limit shows up somewhere else. AI tools are optimized to deliver code that runs, and running is not the same as restricting access. That is why human review of AI-written code is not a formality: at Wama, every result that comes out of Claude Code goes through human reading before it reaches the client.

The prototype answers whether anyone wants the product. It does not answer whether the product can handle customers who do not know each other using the same database, and that is where the step between showing and operating appears.

What 2026 research found in apps built with AI

In Veracode's report on the security of AI-generated code, published in July 2026, models write syntactically correct code almost always, but pass security tests in 56% of tasks. In the first report the rate was 55%: the models got better at coding, not at protecting.

Symbiotic Security, a company that sells a security tool for AI-generated code, analyzed 1,072 apps built on vibe coding platforms with a Supabase database and published in June 2026 that 98% had at least one flaw. In 16% there was a critical flaw, and in 172 of them anyone could delete database records without logging in.

Escape, another security testing company, examined more than 5,600 public applications created with these tools and found more than 2,000 vulnerabilities and 175 cases of exposed personal data, including medical records, in research published in October 2025 and updated in June 2026. And Georgia Tech researchers counted 35 public vulnerabilities attributed to code from AI tools in March 2026 alone, against 6 in January, according to a Cloud Security Alliance research note.

Which flaws repeat in a SaaS built with AI?

Three flaws repeat across the surveys and in what the platforms themselves document. The first is database authorization. In Supabase projects, the rule that decides who reads each row is called RLS (Row Level Security), and the Supabase documentation on RLS warns that an exposed table without this rule can be read and changed by any role with permission on it.

The detail that catches founders off guard: in existing projects, a new table is born with permission to read, insert, update, and delete for logged-out visitors and for logged-in users, and creating a policy does not remove those permissions. The screen works perfectly while the database is wide open.

The second flaw is a secret key inside the code that goes to the browser, like the payment key or an AI API key. One of the most used platforms of its kind reported, in June 2025, that it had started blocking about 1,200 private keys a day pasted straight into the code by users. The third is login without an ownership rule: a person logs in, changes the record number in the address, and opens another customer's data. None of the three shows up in a click test, and all of them are among what usually breaks first when a SaaS grows.

An afternoon test before the first paying customer

You can find a good part of the problem without knowing how to code, as long as the test is done on your own app and with test accounts. No item replaces a technical review; they show whether it is urgent.

1. Two accounts, one customer peeking at the other. Create two accounts, enter data in the first, log in with the second, and try to open the same screens by changing the identifier in the address. If the data shows up, the protection is only in the interface.

2. RLS enabled on every table. In the Supabase dashboard, check table by table and run the security checker (Security Advisor). A table with customer data and RLS turned off is the most serious item on the list.

3. Keys out of the browser. Open the source code of the published page and search for words like secret and service_role. The Supabase public key appears there on purpose and is only safe with RLS on; a secret payment, AI API, or admin key never should.

4. Sign-up with confirmed email. Check that the account only activates after the email is confirmed. The June 2026 scan found confirmation turned off in 69 apps.

5. A backup that restores. Restore a copy of the database into a test project. A backup that has never been restored is a hypothesis.

With the second account, repeat the path of the product's first session: sign-up, first action, and home screen. It is the path every new customer will take, so it is the first one that needs to be locked down.

What does the LGPD require when data leaks?

It requires fast notification, and the obligation falls on whoever controls the data, usually the company that owns the product, not the platform where it was built. Under Article 48 of the LGPD (Brazil's data protection law), an incident that may cause relevant risk or harm must be reported to the ANPD (Brazil's data protection authority) and to the data subjects. Resolution CD/ANPD No. 15, of April 2024, set the deadline at three business days, according to the ANPD's incident reporting page, updated in August 2026.

The report can be supplemented, with justification, within 20 business days, but notifying only the ANPD does not meet the obligation when there is relevant risk: the affected people need to know. The authority can apply the sanctions in Article 52 to anyone who does not report or does not adopt security measures compatible with the risk.

The report asks, among other things, for the security measures adopted and the risks to data subjects. In an app with no access log, answering that in three business days becomes guesswork.

Stay on the builder, reinforce, or rebuild

The decision depends less on the tool and more on what the product stores and how many customers share the same database. The table sums up four scenarios.

When the client needs to own the code, Wama takes the project to custom development, and a logged-in area, portal, or course becomes a digital product project, with its own scope. Rebuilding does not mean throwing the prototype away: the screens users approved become the specification for the interface design that retains the customer.

How much does it cost to go from prototype to product?

It depends on the path chosen in the table. Reinforcing a small app is review and configuration work; rebuilding is a product project, with design, architecture, and testing. At Wama, a SaaS MVP runs between US$ 4,000 and US$ 20,000 and can get close to US$ 40,000 depending on complexity, a range observed across a base of 50 to 100 quotes.

The prototype helps on one specific point: product decisions arrive tested by real users. It does not shorten the engineering, and Wama's experience with AI shows the same: the tool sped up the building, not the deciding, and the total timeline of the projects did not change. To compare proposals, keep the investment ranges for an MVP in Brazil at hand.

Frequently asked questions about building a SaaS with AI

Can you build a SaaS with AI without knowing how to code?

You can build a working prototype, with login, a database, and screens, and validate the idea with real users. Charging customers on top of that prototype is another stage: it requires checking database authorization, keys, sign-up, and backups, which calls for someone able to read the code or at least the configuration.

Doesn't the AI platform already take care of the app's security?

Partly. One of the most used platforms of its kind started running a check before publishing, but it states, in its own text about security, that it cannot guarantee the app comes out 100% secure. The configuration of the database and permissions remains the responsibility of whoever publishes and operates the product.

What is RLS in Supabase?

RLS, or Row Level Security, is the Postgres database rule that decides which rows of a table each user can read or change. In Supabase, an exposed table without RLS is accessible to any role with permission on it, which is why the documentation advises enabling RLS on every exposed table.

Do I need to notify the ANPD if the app leaks data?

If the incident may cause relevant risk or harm to the people affected, yes. Under Resolution CD/ANPD No. 15/2024, the report goes to the ANPD and to the data subjects within three business days and can be supplemented later. The obligation falls on whoever controls the data, usually the company that owns the product.

Can the product's website also be built with AI?

It can, with less care, but not none: a contact form also stores personal data, and the June 2026 scan found open lead tables in 10 apps. The bar for structure and conversion is a different one, covered in the guide on how to structure the website that presents the product.

If your product already has people using it and you want to decide between reinforcing and rebuilding with a team that designs and develops SaaS from brief to deploy, talk to Wama about your SaaS.