Like ’em or hate ’em paywalls have been around since the early days of the web. And from the business perspective I fully understand why they exist: At the end of the day the business needs to make revenue. Throw a stone and you can hit a start-up that “We missed our opportunity to monetize the product”. In this article paywall will refer specifically to services that show some content but hide the rest from viewing unless the user pays a fee. Typically seen on news or informational sites like the New York Times.
When creating a pay wall the implication can (and does) get complicated quickly. Use cases, accessibility, functionality. Then there is the business requirement timelines that push 1/2 baked ideas to production. What I am about to call out is one such idea:
Using cookies to track viewed content and CSS and JS to hide content once the user has viewed over the “limit”….like how Medium does it.
The TL;DR is that once you view X number of aricles (the count is stored in a client side cookie) there is CSS/JS that _hides_ the majority of an articles content unless you pay. What would I be paying for? Not right click->Inspect, find the element overlaying the content and hitting delete? Color me NOT impressed.
Medium: no wonder no one pays for your content. To everyone else: if you are going to have a pay wall, do it from the beginning. Do not change features that were once free to paid only. That is a really shitty bait-and-switch tactic and it stinks (Slack). Instead, offer an intro feature set and additional VALUABLE features for a paid amount.
Sorry about the rant. This just really bugs me how business runs all over engineering sometimes. Hopefully going into the next decade people become more aware of what it is they provide to an organization (views, advert revenue) and demand more from the orgs.
