_by Kulsum Shannan
_Disclosure: I intern at Perfai Security, the tool used for the security testing described below. But I want to be upfront about something else too: GardenOS wasn't built to test Perfai. I built it because I actually wanted this app to exist. The security testing came after, because I cared about the product enough to want it to be safe.
Why I Built This
I garden on and off, and every year I lose track of what I planted, when I watered it, and what actually worked from one season to the next. Notes end up scattered across notebooks, phone photos, or nowhere at all, and by the next spring most of it is forgotten.
I wanted one place where a garden's history sticks around instead of resetting every spring: every plant's care history, journal entries, and harvests kept in a continuous record. I also wanted a way for family or a helper to check in on the garden without risking someone logging a task wrong or deleting a plant record I'd spent a season building. That's what became GardenOS: a role-based garden platform where an Owner holds real authority, an Admin can manage day-to-day without full access control, a Gardener can log care and add journal entries, and a Viewer gets visibility without any risk to the data.
I built it with Lovable, starting from one long, detailed prompt covering the product, the roles, the pages, the workflows, and the technical architecture. It came together fast, and by the end of the process it looked like a real, finished product. Accounts worked, dashboards were role-specific, data persisted, and it was live at a public URL.
That's usually where the story of a vibe-coded app ends. This post is about why it shouldn't be.
The Point of This Post
I'm not writing this just to talk about GardenOS. I'm writing it because I think a lot of people building with AI app builders right now, tools like Lovable, Bolt, and v0, are stopping at the same point I almost did: the app runs, it looks polished, it demos well, so it must be done.
It isn't. And the gap between "this app works" and "this app is safe to put real users' data into" is not something these tools check for you. That gap is the actual subject of this post.
What "Published" Actually Proves
Publishing GardenOS took a few clicks. Lovable generated a live URL, and from that point on, anyone could visit the app, sign up, and use it.
But here's what that step does not prove:
- That the authorization model holds up under direct requests to the backend, not just clicks in the UI
- That a Viewer on one garden has no path, intentional or accidental, to reach data belonging to a garden they aren't part of
- That someone can't reach another user's private plant records or journal entries by manipulating a request
- That authentication endpoints are resistant to abuse
None of this shows up when you're using the app normally. The dashboards look properly separated. The role restrictions look like they're working: buttons are hidden, pages redirect where they should. That's exactly what makes this gap dangerous: everything looks fine from the front end, which is the only view most builders ever check.
Role logic in particular is deceptive. Getting Owner, Admin, Gardener, and Viewer permissions to behave consistently across gardens, plants, tasks, and journal entries took more iteration than any single feature in the entire build. Hiding a button in the UI is trivial. Making sure that restriction actually holds everywhere the underlying data is touched, every API call, every database query, is a completely different problem, and it's not one that "the app works when I click around it" can answer.
Why I Tested It Anyway (and Why You Should Too)
Before treating GardenOS as release-ready, I ran the live deployment through Perfai Security. I want to be clear about what that step was and wasn't:
It wasn't a rebuild. It wasn't a second development phase. It was a release check, the same category of thing as confirming the app works on mobile, that environment variables are configured correctly, or that error states behave the way they should. Perfai tested the deployed application directly: it mapped the app's accessible functionality, roles, routes, and requests, and then tested each of those for weaknesses, rather than just reviewing the source code or the interface Lovable generated.
The first scan found 0 critical issues and 11 medium issues.
I’m glad that there were no critical issues. There were a few medium issues, but when I looked through them they didn’t seem too important. It was a good practice to run my app so I can be confident that my app is ready. There have been times when the Perfai results show many critical issues.The design was polished. The dashboards were separated by role. Authentication existed and worked. Every normal flow I tried behaved exactly as expected. If I had stopped at "it works when I use it," I would have shipped an app with 8 critical authorization problems and had no way of knowing it.
I fixed the issues and ran the scan again. That second pass came back clean.
The Actual Takeaway
Lovable did exactly what I asked it to do, and it did it fast. Turning a long, detailed product spec into a working, full-stack application is genuinely impressive, and I don't think that capability should be undersold. But building the product and confirming it's safe to release are two separate jobs, and only one of them is something a vibe-coding tool does for you.
If you're building anything that touches accounts, roles, permissions, or other people's data, which is most real products, "it's published and it works" is not the same claim as "it's safe to hand this to real users." Making sure it doesn't leak data, doesn't let one user reach another user's records, and doesn't have an authorization model that only exists in the UI is a distinct step. It has to happen after the build, against the live deployment, not just by reading the code or clicking through the demo.
Security testing isn't a replacement for building the product, and it shouldn't overshadow it either; the product still has to be worth using. But it is one of the checks required before anything handling accounts, permissions, and personal records can reasonably be called ready. I used Perfai because I intern there and it's the tool I know best, but the underlying point holds regardless of which tool you use: run something against the live, deployed version of your app that actually tries to break the authorization model, before you call it done.
Try GardenOS:
I'd genuinely appreciate your feedback, both on the app itself, and on whether this changed how you'll think about the "last step" before shipping something you built with an AI app builder.
Top comments (0)