There's a moment in every SaaS product's life where you have to stop building features and start figuring out how to actually charge for them. For TestPlan, that moment arrived on a Tuesday afternoon, and by the end of the same session, I had a pricing strategy, a competitive analysis, and a working Stripe integration. All built in one sitting, with AI acting as both business strategist and engineer simultaneously.
That sounds like marketing copy. I promise it's not. It was messy, iterative, and involved multiple wrong turns. But it happened, and the fact that it happened in one continuous session is the point.
Starting With Too Many Tiers
My first instinct was four pricing tiers. Free, Starter, Professional, Enterprise. That's what everyone does, right? You look at any SaaS pricing page and there are four columns with a gradient of features.
I connected Stripe as an MCP server and told Claude to help me design the billing system. We started with those four tiers, and almost immediately Claude pushed back. Not on the technical implementation - on the strategy.
Four tiers creates decision paralysis for a product that's still establishing itself. The difference between Starter and Professional was blurry. I was splitting features across tiers to justify the tiers' existence rather than because the split made sense for customers. Classic mistake, and one that Claude caught because I'd asked it to think about this from a customer perspective, not just a revenue perspective.
So we simplified. Three tiers: Solo at $49/month, Team at $149/month, Enterprise at custom pricing. The naming tells you who it's for. The pricing tells you what segment you're in. No ambiguity, no "which one is right for me" paralysis.
The Free Tier Question
This led to a genuine strategic debate - with an AI, which still feels slightly ridiculous to type. I asked Claude: "Can you check what the competition does? Do they use free tiers, or is it worth just making people start paying with a trial and money-back guarantee?"
Claude analysed the competitive landscape across TestRail, PractiTest, Zephyr, qTest, and a handful of others. The findings were interesting: most established players don't offer a free tier. They offer trials - 14 or 30 days - and then you're paying. The ones that do have free tiers tend to be newer entrants trying to build market share, and those free tiers are heavily limited to the point of being demos rather than usable products.
The strategic question was whether TestPlan, as a newer entrant, should follow the established players or the challengers. We went back and forth on this. A free tier drives sign-ups but attracts users who may never convert. A trial with money-back guarantee signals confidence in the product but creates a higher barrier to initial engagement.
We landed on a trial approach with a generous money-back guarantee. The reasoning: TestPlan's value proposition becomes clear quickly once you start using it, so the trial period is less about convincing people to pay and more about giving them enough time to set up properly. If the product can't convince someone to pay after a proper evaluation, a free tier wouldn't have converted them either - it would just have given them a place to sit without committing.
AI Credits: The Billing Problem Within the Billing Problem
TestPlan has AI features - test case suggestions, automated analysis, that sort of thing. These features cost me money every time someone uses them, because they're powered by Azure OpenAI under the hood. So I couldn't just include "unlimited AI features" in every tier without potentially losing money on heavy users.
This is where the session got properly interesting, because Claude had to think about this as both a business problem and a technical one simultaneously.
The business problem: how do you price AI features fairly without making the pricing confusing? The technical problem: how do you track, limit, and enforce AI usage per account per billing period?
We designed a credit system. Each tier includes a monthly allocation of AI credits. Credits map roughly to Azure OpenAI token costs with a margin built in. Solo gets enough credits for regular use. Team gets significantly more. Enterprise gets custom allocations negotiated per contract.
The enforcement was the fiddly part. When a user hits their credit limit, AI features don't just break - they grey out with an upgrade prompt. "You've used your AI credits for this month. Upgrade to Team for 3x the allocation, or wait for your credits to reset." It's not aggressive. It's not a hard wall. It's a nudge that happens to also protect my Azure bill.
Claude built the whole credit tracking and enforcement system. Middleware to check credit balance on AI-powered endpoints. A service to deduct credits based on actual token consumption. UI components that show remaining credits and handle the greyed-out state. The Stripe webhook handlers that reset credits on subscription renewal.
All of this was happening in the same conversation where we'd been discussing competitive positioning twenty minutes earlier. That's the bit that still gets me. The same AI session went from "what do our competitors charge" to writing Stripe webhook handlers. There's no human consultant or developer who operates across that range in a single sitting.
Wiring Up Stripe
The Stripe integration itself was surprisingly smooth, mostly because Stripe's API is well-designed and well-documented, and Claude clearly knows it inside out.
Products, prices, subscription creation, customer portal, webhook handling for lifecycle events - the standard SaaS billing stack. Claude set up the Stripe products and prices through the MCP connection, then built the .NET integration to handle subscription management. Checkout sessions for new subscriptions, customer portal sessions for managing existing ones, webhook endpoints for keeping our database in sync with Stripe's state.
The only real friction was around webhook signature verification. There's a specific way Stripe signs webhooks, and the request body needs to be read as a raw string before ASP.NET Core's model binding gets its hands on it. Claude got this right on the first attempt, which honestly surprised me - I've seen experienced developers get tripped up by that particular gotcha.
Subscription status changes, failed payments, cancellations, upgrades, downgrades - all handled through webhooks that update our internal state and adjust feature access and credit allocations accordingly. It's not the most complex billing system ever built, but it's comprehensive enough for a product at this stage.
Feature Gating That Doesn't Annoy People
One thing I was firm about: the feature gating had to feel helpful, not punitive. I've used too many SaaS products where hitting a limit feels like running into a wall at full speed. "UPGRADE NOW" in red letters. Features that are visible but locked behind a paywall just to taunt you.
We built the gating so that restricted features are visible but greyed out, with a brief explanation of what tier unlocks them and why. The language is matter-of-fact, not salesy. "This feature is available on Team plans" rather than "UNLOCK PREMIUM FEATURES TODAY!" Because nobody wants to feel like they're being sold to inside a tool they're already paying for.
Claude handled the conditional rendering across the Blazor components. Each feature checks the account's subscription tier and renders either the full feature or the upgrade prompt. It's clean in the code - a simple service call that returns the feature access state - but getting the UI tone right took a few iterations. Claude's first version of the upgrade prompts was too corporate. I told it to tone it down and make it sound like a human being explaining the situation, not a marketing team that had been let loose.
The Competitive Analysis That Changed the Pricing
After the initial pricing was set, I asked Claude to do a deeper competitive analysis. Not just "what do they charge" but "what's their pricing model, what's included at each tier, how do they handle overages, and where are the gaps we can exploit?"
This actually led to a pricing adjustment. TestRail, which is the dominant player in the space, prices per user and it gets expensive fast for larger teams. PractiTest is similar. The gap was in small-to-medium teams who need serious test management but can't justify the per-seat cost of an enterprise tool.
Our Solo tier was already positioned for individual testers, but the Team tier needed to be genuinely compelling for 5-15 person teams. We adjusted the Team pricing to include a generous seat allowance rather than charging per seat on top of the base price. This makes the per-seat economics dramatically better than TestRail for teams in that range, which is exactly where we want to compete.
That's a business decision that came directly from AI-assisted competitive analysis, refined through conversation, and was immediately implemented in the billing system in the same session. Strategy to code, no handoff, no delay.
What This Says About the Future of Building Products
I keep coming back to the range of work that happened in this single session. Competitive analysis. Pricing strategy. Business model design. Credit system architecture. Stripe integration. UI implementation. Feature gating. Each of those is traditionally a different role or at least a different meeting. Product manager, business analyst, developer, designer - all contributing their piece at different times in a waterfall of handoffs and approvals.
With AI, the cycle time collapsed. Not because the decisions were easier or the code was simpler, but because the conversation never had to stop. A strategic insight led directly to an implementation decision, which led directly to code, which led directly to testing, which revealed a strategic question, which looped back to analysis. It's one continuous thread of work.
I'm not going to pretend this replaces having a team of specialists for a mature product with thousands of users. It doesn't. But for a product in its early stages, where speed of iteration matters more than perfection, the ability to go from pricing strategy to working Stripe integration in one sitting is genuinely powerful. And honestly, a bit surreal.
