My name's Em Uzom , and I build websites that collect money every single month without me ever touching Swift, Kotlin, or a single app store submission form. I want to open with that because the first question almost every client asks me is some version of "can we build an app for this?" — and about 90% of the time, what they actually need is a website that knows who's paid and who hasn't.

A few months back, a client I'll call Ronke — she runs a home yoga studio — messaged me asking for "an app like Peloton" for her class library. She'd gotten a quote from a development agency: eleven weeks, a five-figure budget, and a warning that she'd need ongoing developer support just to fix bugs after Apple or Google pushed an OS update. She didn't have that budget, and honestly, she didn't need an app at all. She needed three things: a way for people to pay her every month, a way to keep non-paying visitors out of her class videos, and a reason for paying members to stick around past month one.

Every one of those three things runs perfectly fine in a browser. No app store review. No download friction. No native code. This post is the exact process I used to build Ronke's site — the same process I now reuse for every client who says "app" when what they mean is "recurring revenue."

Why a Subscription Website Beats an App (Most of the Time)

Before I touch a single tool, I walk every client through this comparison, because it's usually the conversation that ends the "but we need an app" debate.

The numbers on the left aren't a scare tactic — I've sat in on those agency calls with clients. The gap is real, and for most solo creators and small business owners, it's not a gap worth closing just to get a home-screen icon.

Before you pick a single tool, answer one question honestly: the moment somebody cancels, what exactly do they lose access to?

I've found almost everything people want to charge for falls into one of three buckets, and mixing them up is where most first-time subscription sites go wrong:

• Content — courses, videos, articles, downloadable templates. Something that already exists and gets unlocked.
• Community — a forum, a group chat, live calls, events. Something that happens with other people, ongoing.
• Access to a tool — a calculator, a dashboard, a lightweight piece of software. Something a member does, not just consumes.

For Ronke, it was mostly content (her recorded classes) with a thin layer of community (a comments thread under each video where members could ask questions). Knowing that early meant I didn't waste a week evaluating community platforms she didn't actually need.

This is the decision clients agonize over most, so I only ever present three real paths. Here's how I explain each one, and who I'd point toward it.

Path A — WordPress + a membership plugin

Best if you already have a WordPress site, or you want full ownership of your content and design without a monthly platform tax on top of hosting. This is what I used for Ronke, since she already had three years of blog content living on WordPress and didn't want to migrate anything.

Path B — An all-in-one hosted platform

Best for solo creators who don't want to think about hosting, plugin updates, or security patches. You trade some design flexibility for speed and fewer moving parts.

Path C — Webflow + Memberstack

Best when the visual design of the site matters as much as the paywall itself — this is the path I reach for with clients who care about a distinctive brand look and don't want it to feel like a template.

I default clients toward Path A or B unless they specifically ask for design control worth the extra setup time. Most subscription businesses live or die on the offer and the retention email, not the border-radius on the pricing button.

Underneath almost every option in Phase 2 sits the same engine: Stripe. MemberPress connects to it directly, Memberstack runs on it, and Podia and Outseta both use it to actually move the money. I set up the Stripe account first, before touching any plugin settings, because every membership tool downstream needs it connected before it'll let you create a paid tier.

I always build and test the entire flow in Stripe's test mode first, with a fake card number, before switching to live keys. Here's the flow I'm testing for, in order:

Five links in the chain. If any one of them breaks, a member pays and gets nothing — which is the fastest way to earn a chargeback.

For clients who want a more flexible checkout page than their membership tool offers by default — order bumps, payment plans, one-time-plus-subscription bundles — I sometimes drop in a dedicated cart tool in front of Stripe instead.

This is where the membership plugin actually earns its keep. I create the tiers first — usually a Free, a paid Member level, and sometimes a higher VIP level — then assign specific pages, posts, or categories to each one. Everything else defaults to public.

I always build a small test dashboard early, before real content goes in, just to see what a member is actually going to look at the moment they log in:

The exact three-module test dashboard I build before any real content goes in — it's the fastest way to catch a mis-tagged tier.

Here's what the pricing page ended up looking like once the tiers were locked in:

If someone pays and nothing happens in the next few minutes, they get anxious — and an anxious new member emails asking for a refund before they've even seen what they bought. So the welcome sequence gets built before launch, not after.

For clients with a tighter budget who don't mind a slightly steeper setup curve, I sometimes swap in Make.com instead — the free tier stretches further for a low-volume membership site.

The first subscription site I ever launched, I tested the sign-up flow probably twenty times. I tested cancellation zero times. A member found the cancel link on day four, and it took her three support emails to figure out where it was. That's now the very first thing I test on every build, before I even look at the sign-up form.

I never launch to cold traffic first. Ronke's site opened quietly to her existing email list before a single social post went out, which gave us a small, forgiving sample to watch for friction. Two tools did most of the watching:

Ronke's actual soft-launch numbers, week one. The eight-visitor gap between "started" and "completed" checkout was worth investigating on its own.

Mistakes I Made So You Don't Have To

The Full Stack, in One Place