How to Charge for Your App: The Consultant's Playbook

The transition from free to paid

One consultant built a client onboarding tool in Lovable over a weekend. It replaced a manual process that took their team 4 hours per new client. They gave it away to their first 3 clients for free, "just to test it." Six months later, 12 clients were using it and they still had not charged a cent.

The problem was not that the app was not good enough. The problem was that the consultant did not believe they deserved to charge for something an AI helped them build. This is the most common trap.

Here is the truth: your clients do not care how you built it. They care that it works and saves them time. The tool that replaced 4 hours of manual work is worth money regardless of whether you coded it by hand or prompted it in Lovable.

Choosing your pricing model

There are three models that work for apps built by consultants and freelancers:

Flat monthly subscription works best for tools that provide ongoing value. If your client uses the app every week, charge monthly. Start at a price point between what the client would pay a junior employee for the same task and what they would pay a SaaS tool. For most B2B micro-SaaS products, this means somewhere between $49 and $299 per month.

Per-seat pricing works when multiple people in the client's organization use the tool. Charge per user per month. This scales naturally as your client grows and aligns your revenue with the value delivered.

Project-based or annual contracts work for enterprise clients who prefer predictable budgets. Offer a 10-15% discount for annual prepayment. This gives you cash upfront and reduces churn.

Setting your first price

Most builders agonize over pricing and end up too low. Here is a simple framework:

1. Estimate the manual cost your app replaces (hours saved per month times hourly rate of the person doing the work)
2. Price your app at 10-20% of that cost
3. If the manual cost is $2,000/month in labor, your app should cost $200-400/month

This is the "no-brainer" zone. Your client saves 80-90% compared to the alternative, and you capture real revenue.

If your price feels too high, it is probably right. If it feels comfortable, it is probably too low.

Setting up Stripe

For Lovable apps, the standard payment stack is Stripe connected through Supabase Edge Functions:

1. Create a Stripe account and get your API keys
2. Store the secret key in Lovable Secrets (never in frontend code)
3. Create a Stripe Checkout session through an Edge Function
4. Redirect users to the Stripe-hosted payment page
5. Handle the webhook to activate the subscription in your database

You do not need to build a custom payment form. Stripe Checkout handles the entire payment flow, including card validation, SCA compliance, and receipt emails. Your job is just the redirect and the webhook.

Access gating

Once payment is set up, you need to gate access. The simplest approach:

1. Add a subscription_status column to your users table
2. Update it via Stripe webhooks when a payment succeeds or fails
3. Check this column in your route guards and RLS policies
4. Show a paywall for users without an active subscription

This is the minimum viable gating. You can add trials, grace periods, and plan tiers later. Get revenue flowing first.

The pricing page

Your pricing page needs three things:

1. One clear price (do not offer multiple tiers initially)
2. What the user gets (features list, not technical specs)
3. A call to action that says "Get started" not "Buy now"

Keep it simple. One plan, one price, one button. You can segment later when you have 50+ paying users and data on what features matter.

When to raise your price

Raise your price when one of these happens:

• More than 50% of prospects say yes without negotiating
• You have a waitlist or capacity constraints
• You add a feature that meaningfully increases the value delivered

Never lower your price to attract users. If people are not paying, the problem is positioning or product-market fit, not price.

Common mistakes

Offering a free tier: Do not give away the core product for free. If you offer a free plan, it should be genuinely limited (read-only, or capped at a level that prevents real use). A free tier that is too generous cannibalizes your paid users.

Waiting for the perfect moment: There is no perfect moment. If one person would pay for your app today, start charging today.

Discounting for early adopters: Early adopters should pay full price. They get the benefit of shaping the product through feedback. That is the discount.

Pricing based on your costs: Your hosting costs $20/month. Your app saves $2,000/month in labor. Price based on value, not costs.