祝融说。

Pricing is the most headache-inducing and error-prone aspect for every indie developer.

Deep down, many of us carry a "creator's pride" and an "engineer's humility." We love creating but feel awkward talking about money. We fear pricing our product too high will "scare away" users. We also worry that pricing too low will fail to honor the effort we have poured in. This contradictory mindset has caused countless excellent, "love-fueled" products to quietly fade away because they could not sustain themselves financially.

You must remember one truth from day one: Pricing is not a math problem. It is a psychology problem. It is not about calculating your costs. It is about communicating your product's value.

A good pricing strategy can:

• Filter for your ideal customers: Users willing to pay for value are usually the best users.
• Support your sustainable development: Provide you with enough revenue to continuously maintain and iterate your product.
• Shape your brand positioning: Are you cheap "fast food" or premium "Michelin-starred"? The price itself tells your brand story.

This chapter will provide you with a complete commercialization decision framework to help you overcome "pricing phobia" and secure the reward that you and your product deserve.

11.1 Subscription vs. One-Time Purchase: How Should Indie Developers Balance Cash Flow and Long-Term Value?

Before you set a price point, you must make a more fundamental business model choice: will your users "buy" your product once, or "rent" it on an ongoing basis?

These two models are one-time purchase (LTD) and subscription. This choice will fundamentally determine your company's cash flow structure, user relationship, and long-term valuation.

One-Time Purchase: A Short-Term Stimulant, A Long-Term Poison?

• What it is: Users pay a larger one-time fee (say, $49, $99, or $299) for "permanent" access to the product.

• The lure for indie developers:

  • Quick cash flow: In the early stages of a product launch, LTD can bring a surge of upfront cash. Collecting thousands or even tens of thousands of dollars in a single day is incredibly tempting and can greatly relieve early financial pressure.
  • Lowers users' decision threshold: For users who hate subscriptions, the promise of "pay once, own forever" is very attractive, significantly improving conversion rates during cold start. Many products debut on LTD platforms like AppSumo to gain initial users and capital.

• The hidden "devil":

  1. Revenue "rollercoaster": Your income comes in "pulses." A big wave at launch, then long silence until your next major version or new product. You cannot predict next month's revenue, and life is full of uncertainty.
  2. "Permanent" maintenance cost: You have promised "permanent" access, meaning you have taken on a "permanent" responsibility. As long as your LTD user is still using your product, you need to provide customer support, fix bugs, and even cover the server costs they incur (if your product has cloud services). Your costs are ongoing, but your revenue was one-time.
  3. Misaligned incentives: In the LTD model, you make money by constantly attracting new users. You lack incentive to serve existing users well, since they will not pay you again. This pushes you to constantly chase the next "shiny new feature" to attract new customers, neglecting product stability and support for existing users.
  4. Extremely low valuation ceiling: If you ever want to sell your product (see Chapter 13), an LTD-based product will have a very, very low valuation. Acquirers see unpredictable cash flow and a large group of "permanent liabilities" that only consume, not produce.

Subscription: The Long-Term Path to Sustainable Income

• What it is: Users pay a smaller monthly or yearly fee (e.g., $9/month or $90/year) for ongoing access to your product and service.

• The challenge for indie developers:

  • Slow start: Early revenue growth is very slow. The first month might bring just a few users and a few dozen dollars. This requires patience and confidence.
  • Higher marketing threshold: Convincing a user to "commit" to an ongoing payment is harder than convincing them to "impulse buy" once.

• The incomparable long-term advantages:

  1. Predictable recurring revenue (MRR/ARR): This is the most charming aspect of the SaaS model. In a healthy SaaS, monthly recurring revenue tends to grow relatively steadily (provided acquisition and retention stay in balance — there is no automatic snowball guarantee). You can reasonably estimate your revenue range for next month, allowing you to plan your life and business with more confidence.
  2. Highly aligned incentives: In the SaaS model, the only way to make money is to retain existing users and prevent churn. This forces you to pour all your energy into making the product better, more stable, and improving service. Your success is tightly tied to your users' success.
  3. Higher customer lifetime value: A user paying $9/month who stays for three years contributes $9 x 36 = $324 in total value (worked example). This typically exceeds a $99 LTD user — provided retention actually spans the full period; monthly churn directly erodes this number.
  4. Higher business valuation: A SaaS business that can generate stable MRR is generally welcomed by buyers on micro-acquisition marketplaces, with valuation multiples typically in the several-times-net-profit range (3x-5x SDE is common, varying with market conditions). (See Chapter 13.)

How Should Indie Developers Choose?

For the vast majority of indie developers pursuing a long-term, stable, free life, the subscription model is unquestionably the superior choice.

You should build your product and business strategy around the SaaS model from day one.

But this does not mean completely abandoning LTD. We can strategically use LTD as a "tactical weapon" at specific stages.

Hybrid Strategy: Using LTD as "Cold Start Fuel"

A very effective strategy is:

1. In the very early stage (Alpha/Beta), offer a limited-time, limited-quantity LTD to your first batch of "die-hard fans" (e.g., followers attracted from Build in Public).
2. Be clear about your purpose: This LTD's goal is not to make money, but to:
   • Acquire your first precious batch of seed users and product feedback.
   • Obtain seed capital to pay for initial costs like servers and SaaS tools.
   • Create a sense of "scarcity" and "urgency" for the product's initial ignition.
3. Set strict boundaries:
   • Limited quantity: "First 100 users only."
   • Limited time: "Offer valid this week only."
   • Clear terms: State in the terms that LTD users have "lifetime access to the current version," and that future "major new modules" may require additional payment. This leaves room for your future development.

Once your product enters the official launch phase, immediately and decisively switch to a pure SaaS subscription model. Do not cling to LTD.

Summary: LTD is a "hunter" seeking one-time, high-value rewards. SaaS is a "farmer" seeking stable, renewable harvests through continuous cultivation. As indie developers craving freedom and stability, our ultimate goal is to become "modern farmers" with automated irrigation systems.

11.2 Price Discrimination and Anchoring: How to Design a Pricing Table That Feels Like a Steal

Alright, you have decided on the SaaS subscription model. Now comes the hardest question: How much should I charge? $9/month? $19/month? Or $49/month?

There is no standard answer. But the good news is, we can use some classic psychological principles to design a pricing table that guides users toward our desired choice while making them feel like they are "getting a deal."

Core Principle: Never Offer Just One Price

If you only offer one price option (e.g., "$19/month"), the user's brain has only one question: "Buy or not?" This is a difficult, binary choice.

But if you offer three price options (e.g., "Basic $9," "Pro $19," "Team $49"), the user's thinking mode shifts magically. Their question changes from "Should I buy?" to "Which one should I buy?"

Offering multiple options gives users a sense of "control" and "comparison." Our job is to design the options so that, through comparison, they naturally gravitate toward the "target option" we most want them to choose.

Psychological Weapon 1: Anchoring Effect

• What it is: When making decisions, people over-rely on the "first piece of information" they receive (the "anchor"). Subsequent judgments are all adjusted around this anchor.
• How to apply it on your pricing page:
  • The traditional approach is to arrange prices from low to high ($9 -> $19 -> $49).
  • A more aggressive approach is to put your most expensive plan first, on the left. > Team $49/mo | Pro $19/mo | Basic $9/mo
  • Psychological effect: The user's eyes land on "$49" first. This price becomes their "anchor." When they then see "$19," they feel "Oh, that is much cheaper -- looks like a great deal!" You have used a high-priced "anchor" to make your target price ($19) seem much more attractive.

Psychological Weapon 2: Center-Stage Effect

• What it is: When faced with multiple options, people have a natural tendency to choose the middle one.
• How to apply it:
  • Always offer three pricing tiers. No more, no less.
  • Place the plan you most want users to buy in the middle.
  • Visually emphasize the middle plan. Give it a different background color, a bolder border, or add a "Most Popular" or "Recommended" badge at the top.
  • Effect: Most users, due to "analysis paralysis" and "herd mentality," will naturally flow toward the "center stage" you have carefully designed for them.

Psychological Weapon 3: Price Discrimination (Value Differentiation)

• What it is: "Price discrimination" sounds negative, but in economics, it refers to offering different prices based on different customer groups or usage scenarios. Its essence is to match your pricing to the "value" users receive.
• How to apply it (designing your tier differences):
  • Your different tiers should not be just "quantitative" differences (like "10 projects" vs. "unlimited projects"). You need to design differences in "value dimensions."
  • Value dimension: Find a metric that directly reflects the value a user gets from using your product.
    • For "Testimonial AI": The value dimension could be "number of quotes generated" or "access rights to advanced AI models."
    • For an AI code assistant: The value dimension could be "number of supported programming languages" or "ability to integrate with a private codebase."
  • Hands-on tier design (using Testimonial AI as an example):
    • Basic - $9/mo
      • Target user: Individual bloggers who need it occasionally.
      • Core value: Satisfies basic, low-frequency needs.
      • Limits: Max 20 quotes per month; standard AI model only; no image export.
      • Purpose: A "starter" option to attract price-sensitive users.
    • Pro - $19/mo
      • Target user: Indie developers, SaaS founders -- our core users.
      • Core value: Provides unlimited, maximum productivity.
      • Features: Unlimited quote generation; advanced GPT-4 model (better results); image export; one-click copy to clipboard.
      • Purpose: Our "profit center." Most users will be attracted by the "unlimited" and "advanced" features.
    • Team - $49/mo
      • Target user: Small marketing teams.
      • Core value: Provides collaboration and branding features.
      • Features: All Pro features; 3 user seats; custom brand logo (on exported images); priority technical support.
      • Purpose: This tier has two main functions: 1) As a high-priced "anchor," making Pro seem cheap; 2) As a channel to "harvest" the budget of enterprise customers with genuinely high-value needs.

The Dynamic Art of Pricing: Do Not Be Afraid to Adjust

Pricing is not set in stone.

• In the early stage, you can price lower to attract initial users and feedback.
• As your product features strengthen and brand awareness grows, you should boldly and regularly raise your prices.
• Price increase strategy: Only raise prices for new users, and promise your existing users "lifetime access to the original price." This not only eliminates pushback from existing users but also gives them a sense of privilege as "early supporters," turning them into your most loyal advocates.

Summary: Designing a pricing table is a carefully orchestrated psychological guide. By offering 3 options, setting a high-priced "anchor," highlighting the "center stage," and differentiating tiers along core "value dimensions," you can cleverly guide most users toward the option that maximizes value for both them and you, and make them feel like they have made a smart, great-value decision.

11.3 The Freemium Trap: Do Not Let Free Users Drain Your Server

"Free" is the most powerful growth drug on the internet. Offering a "freemium" tier seems like a perfect customer acquisition strategy: use the free version to attract a flood of users, then convert a small fraction into paying customers.

Dropbox, Slack, Notion... countless giants' successes are built on the Freemium model. So many indie developers want to follow suit.

But for us "super individuals," Freemium might not be a "miracle drug" -- it could be a "poisoned cup."

The "Death Spiral" of Freemium

1. High "Hidden Costs"

   • Server costs: If your product (especially an AI product) has significant backend computing costs, every free user is "burning" your money. 10,000 free users, even if each only consumes $0.1 in API costs per month, that is $1,000 in net loss per month.
   • Support costs: Free users are often the most frequent source of support requests. They will drain your precious time and energy that should go to serving paying customers.

2. Blurred Product Positioning

   • To support a free model, you must "cripple" the free version's features. This "crippling" boundary is extremely difficult to get right.
   • Too few restrictions, and users have no incentive to upgrade.
   • Too many restrictions, and the free version becomes useless and fails to attract users.
   • You will spend a lot of time on counterproductive tasks like "how to cleverly restrict free users."

3. Wrong Feedback Signals

   • Free users are not your target customers. Their needs are often very different from those willing to pay.
   • If you iterate your product based on feedback from free users, you may steer the product in a "feature-bloated but low-value" direction, moving further away from your paying customers.

A Better Choice for Indie Developers: "Limited-Time Free Trial"

Instead of offering a "permanent but crippled" free version, offer a "limited-time but complete" free trial.

• What it is: Users can experience all the features of your product's "Pro" or "highest tier" without restriction for a period of time (usually 7 or 14 days). After the trial period, they must pay to continue using it.
• Why it is better for indie developers:
  1. Controllable cost: You know each user's maximum cost is the consumption during the trial period. No indefinite "bleeding."
  2. Maximum value demonstration: You let users directly experience your product's most powerful, most complete state. They are paying for a "100-point" experience they have already felt, not for the gap between a "60-point" free version and an "unknown" paid version. This leads to higher conversion rates.
  3. Creates urgency: The trial period countdown is itself a powerful "call to action," pushing users to make a "buy or not" decision before expiry.
  4. High-quality user feedback: During the trial, users will explore all your product's features. Their feedback, based on a complete experience, is extremely valuable for iterating on your "paid features."

Two Main "Free Trial" Models

1. Trial without credit card

   • Process: Users only need an email to start. After the trial, features are locked, and they must pay to continue.
   • Pros: The barrier to starting is very low, maximizing the number of trial users.
   • Cons: Trial-to-paid conversion rate is relatively low, as users must make another decision and enter their credit card.

2. Trial with credit card

   • Process: Users must enter their credit card before starting the trial. When the trial ends, if they have not canceled, the system automatically charges them (per jurisdiction, you must provide clear advance renewal notice and an easy cancellation path — otherwise this may constitute a negative-option marketing violation).
   • Pros: Trial-to-paid conversion is markedly higher than with no-card trials (industry observations show differences of several times, with the exact multiple varying by product). It filters out "just looking" users, leaving only high-intent customers.
   • Cons: The barrier to starting is high and "scares away" many potential users.

How to Choose?

• If your product's Aha Moment is very fast and its value proposition is very clear, you can boldly try the "trial with credit card" model.
• For most indie developers, a safer starting point is "trial without credit card." Focus first on getting as many people as possible to experience your product's value, then use email marketing, etc., to remind and convince them to pay when the trial ends.

Summary: On the path to commercialization, restraint means having the courage to say "no" to the "temptation of free." Do not let free users who generate no revenue drain your time and servers. Choose the "limited-time free trial" model, letting users fully experience your product's complete value within a limited time. This is a more responsible and sustainable business model for both you and your users.

Summary of Chapter 11: We systematically learned how to convert products into revenue.

• On business models, we compared subscription and one-time purchase models, arguing that SaaS is the better long-term path for most indie developers — more predictable and more sustainable, though not an automatically honored promise.
• On pricing design, we used psychological weapons like anchoring and center-stage effects to design a pricing table that guides users and makes them feel like they are getting "great value."
• On free strategy, we analyzed the Freemium trap and chose the more suitable, cost-controllable, and conversion-efficient "free trial" model.

By mastering the art of pricing and getting paid, your product has finally evolved from a "project" into a real "business." But the journey is not over. In the final part, we will explore how to make this business "automated," and how to gracefully "exit" when you want to start your next journey.