Should I push Bubble with custom states or switch tools for my client portal?

[Steven.J]

I’ve been building a client portal in Bubble and hit a wall with complex conditional workflows. The logic for user permissions and data visibility is getting tangled, and I’m not sure if I should try to push the platform further with custom states or if this is a sign I need to reconsider my tool choice altogether.

[George64]

I've been in that spot with Bubble. I kept trying to push the platform with custom states and layered flows, but the permissions got tangled anyway. I added a Roles data type and tied every field visibility to a role, plus privacy rules anchored to that. Custom states helped for quick toggles, but the logic still spread across pages and became brittle when we added a new permission. It felt like firefighting changes in five places instead of one clean rule.

[AlexanderNL]

Honestly I almost ditched Bubble and started a lighter framework, but I stuck with it long enough to surface a few patterns. The fear is always scoring a permission in the wrong place and leaking data. The tradeoff was that the UI felt faster to wire up than wiring a real backend, but the maintainability dropped over time.

[Sophia_G]

One pragmatic move I tried was to compute a canView flag on the current user via a tiny workflow and store it in a custom state, then gate the UI with that single flag. It did cut down duplication, but I still needed special cases for related records and sub-entities. It bought a bit of sanity, but not a cure.

[James57]

Do you think the bottleneck is actually the data model or the platform features, and do you need real time cross portal permissions or is per session enough?