Bigdata's first subscription system
Bigdata had no self-serve upgrade path. When the trial ended, the sales team called you. Designing the system that replaced that process entirely: tier structure, plan selector, checkout, and activation inside the native app.
The trial ended, and a sales rep called you. Maybe.
Bigdata ran a 30-day free trial. When it ended, there was no upgrade path inside the product. No plan selector, no checkout, nothing. If a user wanted to continue, they waited for the sales team to call them. The entire process depended on a person making a phone call at the right time, to the right user, with the right pitch. It was manual, time-consuming, and completely out of the user's control.
Users who were ready to pay had no way to do it themselves. Self-serve trial-to-paid conversion was effectively zero — every conversion required a sales rep to reach out first. Revenue depended on sales bandwidth, not product quality. Any user who hit the trial limit before that call came through had one option: leave.
The task was to replace that process entirely: design Bigdata's first self-serve subscription system from zero, including the tier structure, the plan selector, the checkout flow, and the activation moment inside the native app.
My scope
Co-defined the subscription model with product and engineering: tier structure, what each plan included, and the logic for splitting self-serve from Enterprise. Then designed every screen in the upgrade path, from trial expiry through to activation inside the native app.
Three tiers, two purchase paths
The subscription model landed as three tiers: Pro ($50/month billed annually), Pro + Investor Bundle ($100/month, targeting financial data professionals who need earnings calls, SEC filings, pricing data, and sentiment analysis), and Enterprise at a price set by conversation.
The two-path decision was a product call, not a UI choice
Showing "Talk to us" instead of a price for Enterprise wasn't a design preference. Pro and Investor Bundle have fixed scope you can evaluate and buy in a few taps. Enterprise means shared infrastructure, dedicated account management, and an organizational rollout that doesn't reduce to a checkout flow. Making that distinction explicit in the product architecture was a joint call with product, and it maps directly to how each customer type actually buys.
The checkout had to live in a browser. Inside a native app. Here's why that's a problem.
The checkout opens in the browser rather than inside the native app. Payment processing via Chargebee ran on the web, an engineering constraint that created a real design challenge: how do you keep the experience from feeling like the user just left the product?
The answer was to keep the checkout linear and minimal: cart with a clear order summary, a single "Proceed to Checkout" CTA, then a consolidated billing screen showing account details, billing address, and payment method in one place before confirming. No extra steps, no upsells, nothing that competes with the main action. Chargebee handles the security layer. The design handles clarity.
Paid. Confirmed. Now get them back into the product.
After payment, the user sees a confirmation screen in the browser with a "GET STARTED!" CTA. That button closes the web view and hands them back to the native app, where a loading state bridges the gap while the backend provisions the new plan. The loading state exists because there's real work happening: features unlock, content access changes, the UI updates to reflect the new tier. Showing that process instead of hiding it tells the user something is happening on their behalf.
Trial-to-paid conversion moved into the product.
Before this shipped, the self-serve trial-to-paid conversion rate was zero. Not low — zero. Every single conversion required a sales rep to reach the user at the right moment. After launch, the team confirmed conversions were coming in without sales involvement. We tracked the split between sales-assisted and self-serve conversions as the primary success metric. Users who were ready to pay could now do it on their own schedule — no sales call required.
What I take from this
Most subscription work is about optimizing a flow that already exists. This was replacing a process that was never a product. The real design challenge wasn't the checkout screens. It was making a user-driven upgrade path feel as trustworthy as a conversation with a salesperson, without the salesperson.
- Designed a complete subscription system from nothing: tier structure, every screen in the upgrade path, and the handoff between web checkout and native app.
- Solved a real constraint: a web checkout inside a native app, kept minimal and with a deliberate re-entry moment rather than leaving users stranded in a browser.
- Co-defined a business model alongside product before designing a single screen. The two-path architecture maps directly to how Pro and Enterprise customers buy, not to what was simplest to build.
- Defined trial-to-paid conversion — self-serve vs. sales-assisted — as the primary success metric before launch, then tracked the post-launch split to confirm the dependency had shifted.