Add a Pro plan and gate features

What's really being asked

This examines whether you can design entitlements that scale beyond two tiers and resist becoming spaghetti. The naive approach, a boolean isPro checked inline everywhere, breaks the moment a third plan or a per-feature add-on appears. The interviewer wants a data-driven, server-enforced design.

The full answer

Introduce a subscription or plan entity associated with the user, carrying plan type, status, and renewal data synced from the billing provider. Rather than checking the plan name directly in features, model capabilities as named entitlements, such as can_export or max_projects, and map each plan to a set of entitlements. Features then ask one question, does this user have this entitlement, through a single central authorization service. This decouples feature code from plan structure, so launching a third tier is a data change, not a code sweep. Enforce every gate on the backend; the client may hide a button for UX, but the server is the source of truth because clients can be bypassed. Handle plan changes, downgrades, and lapsed payments by recomputing entitlements from current subscription state.

The mistakes people make

Adding a boolean isPro and writing if checks across the codebase. Gating only in the UI, leaving the API open to anyone who calls it directly. Hard-coding plan names into features, so every new tier touches every feature.

What usually comes next

How do you handle a user who downgrades mid-cycle? Where do you cache entitlements for performance? How does the billing provider's webhook keep plan state current?

A concrete example

A user upgrades to Pro. Stripe sends a webhook; your backend updates the subscription record and recomputes their entitlements to include can_use_advanced_export and a higher project quota. When they hit the export API, a central check confirms the entitlement and allows it. Later you add a Team tier purely by defining a new entitlement set, no feature code changes.