Snapfix was moving to a subscription model.

​

That created an immediate tension. Users were already running daily operations inside the product - tasks assigned, teams coordinated, workflows in motion. Introducing limits into that environment meant interrupting work that teams depended on.

​

A traditional paywall would have solved the business problem and created a UX one.

The challenge wasn't adding a paywall. It was introducing monetisation in a way that didn't break the product people were already relying on.

Plans were being defined: Basic, Team, Pro, Enterprise.

But the product had no way to show:

• what each plan included
• what was restricted
• when limits would be reached

​

Without that, users would only discover limits when something stopped working.

That creates friction:

• actions blocked without warning
• confusion around what is available
• no clear reason to upgrade

​

This wasn’t just a pricing problem.
It could affect how the product would be used day to day.

A soft paywall strategy was designed to be introduced across the product.

Instead of blocking users, the system:

• surfaces plan limits in context
• highlights upgrade opportunities at relevant moments
• allows users to continue working while understanding restrictions
  
  

Monetisation becomes part of the workflow, not an interruption.

Led the design of the paywall across web and mobile.

Defined how limits appear, how upgrades are introduced, and how monetisation fits within existing workflows.

Worked with product and engineering to align the solution with how Snapfix already operates.

I looked at how other products introduce monetisation and how users experience limits.

What I saw:

• Hard paywalls interrupt workflows and create frustration
• Users respond better when value is shown before restriction
• Soft limits help users anticipate constraints
• Clear plan comparison improves upgrade decisions

​

These insights shaped the direction toward a non-disruptive approach.

Balancing business goals with usability.

The product needed to:

• encourage upgrades
• introduce plan limits
• avoid interrupting work

​

A traditional blocking paywall would solve monetisation, but damage the user experience.

Monetisation was designed around roles and responsibilities within the product.

Upgrade decisions are only relevant to admins, while end-users need to continue their work without interruption. Introducing restrictions at the wrong level would impact daily operations without enabling action.

To address this:

• admins are given visibility into plans, limits, and upgrade options
• end-users can continue using features, even when limits are exceeded

This separation maintains workflow continuity while ensuring the right users are exposed to upgrade decisions.

In parallel, usage visibility enables a more proactive upgrade approach.
Rather than forcing users to upgrade at the point of restriction, exceeded limits can be surfaced and followed up through product and customer success.

This allows the product to:

• support discovery of plan value
• maintain uninterrupted usage
• create a clearer and more natural path to upgrade

​

Design Principles

The solution was guided by five principles:

Non-disruptive
No blocking. Work continues for all users

Role-based visibility
Different information for end-users and admins

Early awareness
Limits are visible before they become a problem

Progressive monetisation
Users discover value before being pushed to upgrade

Product-led with support
Upgrade happens through context, with support from sales when needed

The paywall was designed to be embedded directly into the product experience.

It includes:

Plan visibility
Users can see their current plan and included features.

Usage awareness
Visual indicators show when limits are approaching or exceeded.

Upgrade opportunities
Contextual prompts highlight the value of higher-tier plans.

Instead of stopping users, the system informs and guides them.