How to Charge for Vibe-Coded Apps: One-Time Purchase or Subscription?

You built an app with Claude Code, Cursor, or Codex. You already have users, and some have even said they'd be willing to pay. Now you face two questions: how should you charge, and how do you integrate payments without messing it up. The author, Deepak, is an indie developer based in Hyderabad who has integrated payment systems into many AI-agent-built apps. Here's his summary of lessons learned.

Three Main Pricing Models

Almost all small apps use one of the following three models, or a mix:

• One-time purchase: The customer pays once and gets permanent access. Good for templates, tools, lifetime licenses, or downloadable resource packs.
• Subscription: The customer pays monthly or annually and loses access when they stop paying.
• Credits (usage-based pricing): The customer buys a block of usage, such as 100 image generations, and tops up when it runs out.

There's no "correct answer." The right choice depends on one simple question.

The Key Question That Decides Your Pricing Model

Does your app incur costs every time it's used?

If yes, you'll most likely need a subscription or credits. If no, a one-time purchase is often simpler and easier to close.

The reason is that many vibe-coded apps call AI models, send emails, store files, or run on usage-billed servers. As long as customers keep using them, these costs keep accruing. If you only charge once, heavy users could eventually cost you money. Charging monthly or using a credit-exhaustion mechanism keeps your revenue matched to your expenses.

If your app is mainly a fixed-shape product—a calculator, a template, a desktop tool, or a set of files—where costs don't grow significantly with user count, then a one-time charge is both honest and easy for buyers to say yes to.

One-Time Purchase: When It Fits and What to Watch For

Good for: low-cost tools, templates and starter kits, downloadable products, and "lifetime access" launch offers.

Why buyers like it: No worries about yet another monthly bill, simple to explain, and nothing to cancel.

The pitfall: You only get paid once. To keep earning, you need a steady stream of new buyers or paid upgrades later. Be especially careful with "lifetime" offers on apps that call AI models—the costs don't stop.

What you need to set up:

1. Create a product with a single price in your payment platform's dashboard.
2. A "Buy" button that sends users to the payment platform's checkout page.
3. Your app listens for payment messages (developers call these webhooks—automatic "this person has paid" notifications sent by the payment platform) and marks that user as a buyer.
4. The paid page checks "is this person a buyer?" before granting access.

That's it. No renewals, no cancellations—just refunds to handle.

Webhooks and Verification: When a payment platform (like Polar or Stripe) detects a change in transaction status, it sends an HTTP POST request to a URL you configure in your app—this is a webhook. It carries an event type (like payment.succeeded) and a signature header. Your app must verify the signature using the secret provided by the platform (webhook secret) to ensure the request actually came from the payment platform and wasn't forged. After verification passes, parse the event and update the user's permissions. Ignoring verification gives attackers a chance to forge "paid" notifications and gain free access.

Subscriptions: When They Fit and Hidden Complexity

Good for: apps users use regularly, apps with ongoing costs (AI, hosting, data), and apps you keep improving.

Why developers like it: Recurring monthly revenue is easier to plan around and easier to keep paying for servers.

The pitfall: There are more moving parts. Users cancel, credit cards expire, payments fail, and some customers switch between plans. Your app must respond correctly to every one of these cases, not just the first payment. And buyers are more cautious when signing up for something that charges forever.

What you need to set up:

1. A monthly-priced product, optionally with an annual price (usually at a discount).
2. A "Subscribe" button that goes to the checkout page.
3. Your app listens for payment messages—not just "paid" but also "renewal succeeded," "cancelled," "payment failed," and "refunded"—and updates user permissions on every event.
4. The paid page checks "is this subscription currently active?"
5. A "Manage Billing" page so customers can update their credit card or cancel on their own. Both Polar and Stripe provide ready-made pages for this, so you don't need to build from scratch.

Step 3 is where most AI-generated payment setups go wrong. The agent handles the first payment but forgets the subsequent events, leaving cancelled users with permanent access. The author's previous blog post has a checklist to troubleshoot this problem.

Subscription Lifecycle Events: A subscription isn't just "the first payment"—it also includes successful renewals (invoice.paid), failed renewals (invoice.payment_failed), cancellations (customer.subscription.deleted), refunds (charge.refunded), and more. Each event requires your app to adjust user access accordingly. For example, after receiving a cancellation event, you should set an expiration time rather than immediately revoking access, until the current billing period ends. On payment failure, you can give the user a grace period and send a reminder email. Handling these events correctly is key to avoiding lost revenue and user disputes.

Credits: The Middle Ground

If your costs depend heavily on how much users use your app, credits may be fairer than either of the previous two models. Customers buy a block of credits, each use deducts a certain amount, and they top up when the balance is low. Light users spend less, heavy users spend more, and you never lose money on any single person.

The cost: your app must maintain an accurate balance for each user and must never allow the balance to go negative—even if the user clicks twice quickly. This is entirely feasible but requires careful testing.

Atomicity and Concurrency Control: Credit deductions must be atomic—that is, checking the balance and deducting from it must be an indivisible operation. If two requests arrive at the same time, both read a balance of 1, then each deducts 1, the balance becomes -1. Solutions include using the database's atomic operations (such as UPDATE users SET credits = credits - 1 WHERE id = ? AND credits >= 1 and checking the number of affected rows), or using transactions and row-level locks. In distributed systems, you can also use Redis's atomic decrement command. When testing, be sure to simulate concurrent requests to ensure the balance never goes negative.

Can't Decide? Start Simple

If you can't decide, here's a reasonable default:

• Low operating costs: Start with one-time pricing. You can add subscription tiers later.
• Real operating costs (like AI calls): Start with a single monthly plan. Just one. Add an annual option or a second tier once users ask for it.

Whichever you choose, you can change it. Your first price is just a guess, and that's fine. Real customers will tell you more than any pricing article.

Polar vs. Stripe: How Indie Developers Should Choose

Once you've decided how to charge, you need a payment service provider. For most indie developers, the choice comes down to Polar and Stripe. Both handle one-time payments and subscriptions well.

Polar is a merchant of record. In plain terms, Polar is the seller on paper: it handles collecting and remitting sales tax and VAT in the countries where your customers buy, then pays you. If you're selling globally on your own, this saves a lot of paperwork. The trade-off is a higher rate per transaction than Stripe's base rate—check their current pricing page.

Stripe processes payments, but you are the seller, and tax is your responsibility. Stripe has a tax add-on that can calculate the correct amount to collect, but registration and filing are still up to you. In return, you get more control and a massive feature set.

The author's rule of thumb: If you're an indie developer selling digital products or subscriptions to multiple countries and don't want to deal with tax, start with Polar. If you already have a Stripe account or an existing business entity that handles tax, use Stripe. Whichever you choose, first confirm it can pay out to your country. If tax gives you a headache, it's worth spending some money to consult an accountant.

Merchant of Record (MoR): An MoR is the legal seller and is responsible for handling sales tax, VAT, and other tax compliance. For indie developers selling digital products globally, tax rates and filing rules in different countries are extremely complex. As an MoR, Polar calculates, collects, and remits the appropriate taxes on your behalf—you just receive the net payment. This greatly lowers the compliance barrier. Stripe, by contrast, is a payment processor: you are the seller, and tax liability is yours. Stripe Tax can help you calculate the tax amount, but registration and filing are still up to you. Choosing an MoR is essentially trading a slightly higher rate for outsourced tax handling.

Step-by-Step Integration Guide

Whether your app is built with Next.js (the most common setup for vibe-coded web apps) or another stack, the following steps apply. You'll have your AI agent do most of the work, but the responsibility for checking is yours.

1. Create an account: Sign up for Polar or Stripe and stay in test mode (a practice mode that doesn't involve real money).
2. Create products and prices: Set up one-time, monthly, or both in the dashboard.
3. Have the agent add checkout. Be specific in your instructions: "Add a subscribe button that sends logged-in users to the Polar checkout page for my Pro monthly product."
4. Have it handle payment messages, and list all types: paid, renewal, cancellation, payment failure, refund. Require it to verify the authenticity of each message using the secret from the dashboard.
5. Have it lock down the paid page, ensuring the page checks access permissions in the database, not just whether the user saw a thank-you page.
6. Add a billing page so customers can cancel or update their credit card themselves.
7. Test everything with test cards: purchase, log out and back in, cancel, refund, and try the billing page as a free user.
8. Switch to live mode, copy the live keys, make a real purchase yourself, then refund it.

Step 7 is the one most people skip, and it's exactly what saves you from angry support emails.

The All-in-One Solution: ShipToPaid

The author got tired of manually writing these prompts and repeatedly fixing the same mistakes, so he turned the tested steps into written instructions (called skills) for Claude Code, Cursor, and Codex to follow. That's ShipToPaid.

Instead of steps 3 through 6 above, you just type /add-paywall into your agent, say whether you want one-time or subscription, and it follows a checklist that already covers the traps: verifying payment message authenticity, handling cancellations and payment failures, and correctly locking down the paid page. A launch audit feature walks you through testing.

Want to try it first? The free lite pack on GitHub includes Polar checkout, Polar payment messages, and a short launch checklist. The full pack adds Stripe, subscription-based access control, a customer billing page, credits, license keys, and a working Next.js starter app. Every skill is a plain file you can read and modify.

You can also follow this guide entirely without these tools. Choose how to charge, choose a payment provider, walk through the whole flow in test mode, and then go get your first paying customer.

One-line Summary

An indie developer's guide to choosing a pricing model for AI apps and integrating payments reliably.

Paragraph Summary

This article provides a pricing and payment integration guide for indie developers building apps with tools like Claude Code and Cursor. It first analyzes three main pricing models—one-time purchase, subscription, and credits—and points out that the core decision is whether the app incurs ongoing costs each time it's used. It then details the use cases, pitfalls, and required setup for each model, emphasizing the importance of handling subsequent events (cancellations, payment failures, etc.) in subscriptions. Next, it compares Polar and Stripe to help developers choose based on their tax needs. Finally, it provides a step-by-step integration guide and introduces ShipToPaid, a tool that packages payment integration steps into skill files executable by AI agents to simplify the process.