| I vibe-coded a tiny SaaS for about a month with basically zero software background. It works well enough that real users are poking at it, which is exactly when the fun left the room. a dev friend asked one question that ruined my evening. Can user A change an ID in a request and see user B's records. I had no answer. Claude generated a lot of the app and I nodded along becuase the UI looked right. Tenant isolation is not a UI feeling. It is route checks, database policy, ownership, and all the boring stuff I skipped. My current pre-launch panic list is pretty small. two test users, ID swap every route, secrets not in frontend code, sessions that expire, admin routes that normal users cant call, logs that do not dump private data . That question also made me rethink how I built the app in the first place. I had been treating auth, database rules, and server functions as separate Claude conversations, so I was basically inventing permissions one prompt at a time. I started comparing that setup with Enter Pro I used before, where those pieces sit closer together in the same build flow,offered me a clear line of thinking. What I am trying to figure out is whether keeping everything together actually makes the access rules easier to inspect, because a cleaner builder still does not prove tenant isolation For no-code founders, what do you check before real users touch customer data [link] [comments] |