A response to Complexity Levels in Password Protected Content (May 2024)
In May 2024, in my Answering the RFP series, I walked through a requirement that often shows up as a single innocent bullet point: password protected content. My advice was to treat that bullet as a question, not an answer, because there are levels.
The simplest level is one shared password on a page, which WordPress does out of the box. From there it climbs. Individual user accounts. Approval workflows. Paid subscriptions with renewals. Single sign on with a CRM like Salesforce. And I closed with a warning:
“But even with these tools, password protected content still adds significant production costs to a project for the coordination, configuration, and the extra content required.”
That was true then. Some of it is still true now. But the reasons have shifted.
Where the cost used to come from
In 2024 the answer for every tier above a simple page password was a plugin, or a stack of them. A membership plugin for accounts. Its add-ons for payments and renewals. Another tool for single sign on. Then the page builder had to be taught to show and hide content based on who was logged in. I described that part this way:
“most sites with password protected content will have many instances of conditionally displayed content and messages triggered by whether or not a user is logged in.”
Each of those conditions had to be configured, and often worked around, inside tools that were built for many sites rather than yours. Configuration was the expensive part. When a client’s process didn’t match the plugin’s assumptions, we either bent the process or paid a programmer.
What agents change
AI agents now write custom code under experienced direction, quickly and at far less cost than before. That changes the middle tiers most.
Login status indicators, account pages, the logic that shows one message to members and another to visitors: these used to be configuration puzzles. Now they can be written directly into the theme, built around exactly how your organization works. An approval step that matches your real workflow doesn’t need to be forced into a plugin’s settings screen. We can just build it.
For the top tiers, the judgment is the same as it always was. Payments and single sign on involve security and money, and I still prefer mature, well-supported tools for the parts that handle them. The difference is that connecting those tools to a custom site is no longer a heavy lift, so we can keep the dependable core and write the glue around it. We don’t have to accept a clunky experience just to avoid custom code.
That is the real shift. We no longer have to choose between a login experience that fits the client and a budget that fits the client.
What doesn’t get cheaper
Here is the part of my 2024 advice that hasn’t changed at all. The questions I told agencies to ask are still the right questions:
“do accounts need to be pre-approved? And who’ll be responsible for approving?”
Agents can’t answer those. Someone has to decide who gets access, what happens when they lose it, and what every automated email says when an account is created, approved, or expired. That content has to be written by people who understand the organization. The whole flow has to be tested from the user’s side, including every error message and edge case, by someone who cares whether it works.
So when you see that single bullet point in an RFP, you should still follow up with strategic questions. The planning, the content, and the testing are still real work. What has dropped is the cost of building whatever the answers turn out to be.
A different conversation
In 2024 the conversation about protected content was often about what the client would have to give up to stay within budget. Today it is more about what they actually need. That is a better conversation. If you want to understand why development budgets have dropped so much, I explain it in our approach to pricing. And if you are weighing a members area or a subscription site now, let’s talk it through.
¡Viva la Revolución!