Paweł 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. His Lovable app had a generated access policy broader than the team access he requested.
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 generated policy on his 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.
Lovable changed the policy after he asked in chat. He later signed in with a different account and saw no contacts. An attendee also checked after he shared the link; Huryn said he should have tested before publishing.
Who Huryn is
Huryn writes Product Compass and teaches product managers about AI-assisted product work. Huryn has also examined how Claude Code’s system prompt affects agent behavior.
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 produced four CRM prototypes in just over an hour. That demonstrates iteration speed, not that detailed requirements are unsuitable for every project.
His notes point to different trade-offs rather than a single winner. In this exercise, Lovable produced a publishable result quickly, but its access rules still needed a manual check. Google AI Studio synced to GitHub, while its Firestore dependency raised portability questions for Huryn. Claude Design’s interview process shaped the prototype, but its current limits excluded tracking, analytics, and a real database.
Claude Code took longer to set up, yet produced repository-based code. Those observations describe one workshop exercise, not a ranking of the products.
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. The finding illustrates why “any signed-in user” access needs to be checked against the intended users, rather than assumed to mean team-only access.
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. Iteration can help explore early ideas. Security requirements still need explicit checks, and this workshop does not establish a ranking for other projects. A tool’s tradeoffs can shift once your app needs something his one-hour CRM didn’t.
End of article