Pricing Strategy and Implementation
Build a pricing page with plan comparison, A/B testing, Stripe integration, and data-driven pricing optimisation.
Pricing strategy fundamentals for SaaS
Pricing is the most impactful lever in your business. A 1 percent improvement in pricing typically has a 12 to 15 percent impact on profit — more than a 1 percent improvement in customer acquisition or retention. Yet most founders spend weeks on their product and 30 minutes on pricing. The three main pricing models for SaaS are: flat-rate (one price for everyone — simple but leaves money on the table), tiered (multiple plans targeting different customer segments — the most common), and usage-based (pay for what you use — increasingly popular, but harder to predict revenue). For most startups, start with tiered pricing: three plans. Ask Claude Code: Create a Next.js project with TypeScript and Tailwind for a pricing page. Define the pricing data at src/data/pricing.ts with three tiers. Free: limited features, enough to demonstrate value (used for lead generation). Pro: full features for individual users, priced at the perceived value of the problem you solve. Team: everything in Pro plus team features, priced per seat. Each plan needs: a name, monthly price, annual price (discounted — typically 20 percent off), a list of features (with a flag for whether it is included in this plan), a CTA button label (Start Free, Go Pro, Contact Sales), a highlight flag (the plan you want most people to choose), and a description (one sentence positioning the plan). The middle plan should be visually emphasised — this is called the centre-stage effect and it consistently increases selection of the middle option by 20 to 30 percent. Ask Claude Code: Create the pricing data structure with all fields. Include 10 to 15 features that progressively differentiate the plans.
Building the pricing page UI
The pricing page is your highest-converting page — it receives the most commercially valuable traffic. Every element matters. Ask Claude Code: Create a pricing page at src/app/pricing/page.tsx. Start with a headline and subheadline that frame the value proposition, not the cost. Instead of Our Pricing, use something like Choose the plan that fits your workflow or Start free, upgrade when you are ready. Add a monthly/annual toggle. Ask Claude Code: Build a toggle switch that flips between monthly and annual pricing. When annual is selected, show the monthly equivalent price (annual total divided by 12) with a badge showing Save 20 percent. Animate the price change — numbers should count down from the monthly price to the discounted annual price. Display the plans as three cards side by side. Ask Claude Code: Create a PricingCard component. The highlighted plan should have a different background colour, a Recommended or Most Popular badge, and a slightly larger scale (transform: scale 1.02) to draw the eye. Each card shows: the plan name, the price with a billing period label (per month or per month billed annually), the description, the feature list with checkmarks for included features and subtle x marks for excluded features, and the CTA button. Add social proof below the pricing cards. Ask Claude Code: Add a section showing the number of customers (or users, or companies), logos of recognisable customers, and a testimonial from a customer about the value they get from the product. Social proof directly below pricing reduces purchase anxiety. For the team plan, add a seat calculator. Ask Claude Code: Create an interactive calculator where the user enters the number of team members. Show the per-seat price, the monthly total, the annual total with savings highlighted, and a comparison to the cost of alternative tools. This makes the team plan concrete and helps internal champions justify the purchase.
Stripe integration for checkout
Stripe handles payment processing, subscription management, invoicing, and tax calculation. Ask Claude Code: Install Stripe: npm install stripe @stripe/stripe-js. Set up environment variables for STRIPE_SECRET_KEY and NEXT_PUBLIC_STRIPE_PUBLISHABLE_KEY. Create a Stripe product and price for each plan in the Stripe dashboard (or via the API). Create the checkout flow. Ask Claude Code: Build an API route at src/app/api/checkout/route.ts. When a user clicks the CTA button on a pricing card, the client sends a POST request with the selected priceId. The server creates a Stripe Checkout Session with the price, a success URL (your thank-you page), a cancel URL (back to pricing), and subscription mode. Return the session URL and redirect the client. Stripe Checkout handles the entire payment form — card number, billing address, tax calculation, and error handling. You never touch sensitive payment data. Handle post-checkout events. Ask Claude Code: Create a webhook handler at src/app/api/webhooks/stripe/route.ts. Verify the webhook signature using the STRIPE_WEBHOOK_SECRET. Handle these events: checkout.session.completed (a user just subscribed — create or update their account, grant access to paid features), customer.subscription.updated (a plan change — update feature access), customer.subscription.deleted (a cancellation — revoke paid access), and invoice.payment_failed (payment issue — notify the user, provide a grace period). Add a billing portal. Ask Claude Code: Create a Manage Subscription button in the user's settings that redirects to the Stripe Customer Portal. The portal lets users update their payment method, switch plans, cancel, and view invoices — all without you building any billing UI. Configure the portal in the Stripe dashboard with your branding. Common error: webhook events can arrive out of order or be duplicated. Make your handlers idempotent — processing the same event twice should not create duplicate accounts or double-charge customers. Use the event ID to check if you have already processed it.
A/B testing pricing
The only way to find the right price is to test. A/B testing pricing reveals what customers are actually willing to pay, not what you think they should pay. Ask Claude Code: Create an A/B testing framework at src/lib/ab-testing.ts. An experiment has: a name, a list of variants (each with a name and a weight for traffic allocation), and an assignment function that deterministically assigns a user to a variant based on their ID (use a hash function so the same user always sees the same variant). Create a pricing experiment. Ask Claude Code: Define an experiment called pricing-v2 with two variants. Control: the current pricing ($0, $29, $99 per month). Test: higher pricing ($0, $39, $129 per month). Assign 50 percent of traffic to each variant. On the pricing page, read the user's variant assignment and display the corresponding prices. Track two events for each variant: pricing_page_viewed (impression) and checkout_started (conversion). The conversion rate is checkout_started divided by pricing_page_viewed. Build an experiment dashboard. Ask Claude Code: Create a page at src/app/admin/experiments/page.tsx that shows all running experiments with: each variant's impression count, conversion count, conversion rate, and revenue per visitor (if available). Add a statistical significance calculator — show the confidence level that one variant is truly better than the other. A common threshold is 95 percent confidence. Display a clear recommendation: Variant B has a 3.2 percent higher conversion rate with 97 percent confidence. Consider switching to the Test pricing permanently. Important constraints for pricing A/B tests. Ask Claude Code: Implement these safeguards. Never show different prices to the same user across sessions (use a persistent assignment). If a user sees $29 and later sees $39, trust is destroyed. Ensure that checkout uses the price the user saw (pass the variant through to the checkout session). Log every assignment and conversion for audit purposes. Run tests for at least 2 weeks to capture weekly behaviour patterns. Common error: A/B testing pricing is ethically sensitive. You are showing different prices to different people. Mitigate this by testing tiers and feature bundles rather than raw prices — test whether $29 for 5 features converts better than $39 for 8 features.
Feature gating and plan enforcement
After a user subscribes, your application must enforce the plan limits — free users get limited features, Pro users get full access, and Team users get collaboration features. Ask Claude Code: Create a feature gating system at src/lib/feature-gates.ts. Define a feature matrix: a map of feature names to the plans that include them. For example: unlimited_projects is available on pro and team, team_members is team only, api_access is pro and team, priority_support is team only, and export_to_pdf is pro and team. Create a helper function: hasFeature(userPlan, featureName): boolean. Build middleware and UI components for enforcement. Ask Claude Code: Create a server-side middleware that checks feature access before executing gated API routes. If the user's plan does not include the requested feature, return 403 Forbidden with a message like Upgrade to Pro to access this feature. Create a client-side FeatureGate component that wraps gated UI elements. If the user has access, render the children normally. If not, render a locked state — the element is visible but greyed out with an Upgrade to Pro overlay that links to the pricing page. This visibility of locked features drives upgrade conversion — users see what they are missing. Implement usage limits for metered features. Ask Claude Code: Create a usage tracking system. Free plans allow 100 API calls per month, Pro allows 10,000, and Team allows unlimited. Track usage in the database. Before each API call, check the current month's usage against the plan limit. When usage reaches 80 percent of the limit, show a warning notification. When usage exceeds the limit, block the request and show an upgrade prompt. Reset counters on the first of each month. Add a usage dashboard to the user's account page. Ask Claude Code: Show a progress bar for each metered feature: 3,456 of 10,000 API calls used this month. Include a usage trend chart showing the last 6 months. Predict whether the user will exceed their limit this month based on current pace. If they will, show an early warning with an option to upgrade. Common error: enforce limits on the server, not the client. Client-side gates can be bypassed by calling your API directly. Every API route that serves a gated feature must check the plan server-side.
Pricing page optimisation and deployment
Optimise the pricing page for conversions using data and psychology. Ask Claude Code: Add a FAQ section below the pricing cards. Include the top questions: Can I change plans later (yes, upgrade or downgrade anytime), Is there a free trial (yes, the Free plan is a permanent free tier), What payment methods do you accept (all major credit cards via Stripe), Can I cancel anytime (yes, no long-term contracts), and Do you offer refunds (yes, 30-day money-back guarantee). Each question should be an expandable accordion — collapsed by default to keep the page scannable. Add urgency and scarcity elements where appropriate and honest. Ask Claude Code: If running a launch promotion, show a banner: Launch pricing — these rates are locked in for early subscribers. After the promotion period, new subscribers pay the higher rate but existing subscribers keep their original price. Add a countdown timer if the promotion has a real end date. Never fake urgency. Add comparison to alternatives. Ask Claude Code: Create a comparison table below the FAQ that shows your product versus 2 to 3 competitors. Columns: feature, your product, Competitor A, Competitor B. Rows: price, key features, limits. Highlight where your product wins. This is effective because visitors on your pricing page are already evaluating alternatives — give them the comparison on your terms. Implement pricing analytics. Ask Claude Code: Track these events on the pricing page: page load (with traffic source), toggle between monthly and annual, hover over a plan card (with dwell time), click a feature tooltip, open an FAQ item, click a CTA button (with which plan), and checkout completion. Create a pricing page funnel in your analytics: visited pricing, selected plan, started checkout, completed payment. Deploy to Vercel. Ask Claude Code: Configure the deployment with all Stripe environment variables. Test the complete flow: visit pricing, select a plan, complete checkout with a Stripe test card (4242 4242 4242 4242), verify the webhook fires, and verify feature access is granted. Test plan switching and cancellation via the billing portal. Test the A/B testing with different user IDs to verify deterministic assignment.
Monetisation Strategy
This guide is hands-on and practical. The full curriculum covers the conceptual foundations in depth with structured lessons and quizzes.
Go to lesson