1) The problem → When we first built Memberstack, we assumed users would want Memberstack to do all of the content gating and permissions for them. This was an okay assumption for a time, but we've since learned that a more robust system of managing permissions is necessary to expand Memberstack for and beyond the no-code space.

2) What we are building → Permissions! Permissions are strings of text that are stored on the member object, and cannot be updated client-side. This makes them perfect for granting access to members-only content and functionality within your codebase.

Members-only content for Webflow, Squarespace, HTML/CSS, etc. will rely on this new functionality, but will not affect the UI/UX in any way. If anything, it should open up more opportunities for control.