He Tested Four AI Prototyping Tools. One Shipped a Security Hole by Default.

Pawel Huryn ran the same prototyping exercise four times: build the same simple CRM (a customer relationship management tool, for tracking contacts and deals) in Lovable, in Google AI Studio, in Claude Design, and in Claude Code. One of the four had a default setting that let more people see the data than he’d asked for.

In a workshop write-up testing all four tools, Huryn had told Lovable during setup that he wanted “a small team with logins, shared data,” meaning only his team should see the contact records. Before publishing, he checked the tool’s row-level security settings, the rules a database uses to decide which rows of data a signed-in user is allowed to see. The default policy on the contacts table read USING true, and he wrote: “On contacts, mine was USING true, which means any signed-in user, not just my team.” In plain terms, that default would have let anyone with an account on the app see every contact record, not just his team. He caught it by checking the policy screen before publishing, and Lovable fixed it once he asked in chat.

Who Huryn is

Huryn is a product coach and the founder of Product Compass, a newsletter and community for product managers with over 23,000 subscribers, and works as an AI PM coach teaching product managers how to use AI tools. BuilderWithin covered his findings on Anthropic’s Claude Code system prompt on August 12.

What he gets right, and where it’s incomplete

Huryn’s central argument is that specification-driven prototyping, writing a detailed brief before building anything, doesn’t work for early product ideas. He quotes engineering consultant Allen Holub: “I really don’t get ‘spec-based development,’ which is nothing but a fancy way to describe a phase-gated ‘waterfall.’ An upfront specification is never correct.” Waterfall is an older project approach where each stage, like design, then build, then test, has to finish before the next one starts, with little room to go back and change course. Huryn’s alternative, “iterate, don’t spec,” is to give an AI tool the problem and context, build fast, and correct course as you go. His workshop backs this up with a concrete comparison: all four tools built a working version of the same CRM in just over an hour.

His per-tool verdicts are specific rather than vague praise. Lovable published fastest with the best default design, but locks builders into its platform and, as the security example shows, its default access rules need a manual check, not a rubber stamp. Google AI Studio is free to start and syncs to GitHub, but produced the weakest-looking interface and ties data to Google’s Firestore database, which he found isn’t simple to move off of later. Claude Design produced the best-looking prototype through a pre-build interview process, but cannot add tracking, analytics, or a real database, a hard ceiling on what it can become. Claude Code took the most setup time but produced real code in a repository with no platform lock-in, the version he says hands off most cleanly to an engineering team.

What Huryn’s write-up doesn’t settle is how these verdicts hold up outside a one-hour workshop CRM. A more complex app, a different data model, or a team with less AI experience could change which tool’s limits matter most. Huryn’s comparison is a useful data point from one structured test, not a benchmark.

Why it’s notable

The Lovable finding matters beyond that one tool. AI prototyping platforms increasingly generate a working backend, including database access rules, without the builder writing that logic themselves. Huryn only caught the overly broad default because he specifically knew to check the security policy screen before publishing. Most non-technical builders using these tools would not know that screen exists, let alone that “any signed-in user” access was the default.

What it means for builders

If you’re prototyping with an AI tool that spins up a real database, do not assume access controls match what you asked for in the setup conversation. Look for the tool’s data access or security policy settings before you publish, and check them, not just the visible product. Separately, Huryn’s “iterate, don’t spec” approach is a reasonable default for early prototypes, but treat his tool rankings as a starting point for your own testing, not a substitute for it. A tool’s tradeoffs can shift once your app needs something his one-hour CRM didn’t.

End of article