Pricing Experiments: What Worked for My 2026 Launches

I have gotten pricing wrong more times than I've gotten it right. That's not false modesty — it's 30 years of launching products and watching perfectly good software die because I charged too little, too much, or structured the pricing in a way that confused people into closing the tab.

In the past year, I've launched or relaunched three products with deliberate pricing experiments on each one. I tracked every conversion, every refund request, every abandoned checkout. And I learned things that contradict a lot of the standard advice you'll find in indie hacker communities.

Here's the full breakdown — actual numbers, actual mistakes, and what I'd do differently.

---

The Three Products

Let me set the stage with what I was pricing:

Product 1: A technical ebook about training and fine-tuning LLMs. This is my book that I sell through Grizzly Peak Software. It's a niche technical resource aimed at experienced developers who want to understand LLM training from the ground up.

Product 2: AutoDetective.ai API access. AutoDetective is my vehicle diagnostics platform. The consumer-facing side is free (ad-supported), but I launched a paid API tier for mechanics shops and fleet management companies in early 2026.

Product 3: A premium job board listing tier. The Grizzly Peak Software job board is free for basic listings, but I experimented with a paid tier that includes featured placement, extended listing duration, and company branding.

Three very different products, three very different markets, three very different pricing lessons.

---

Product 1: The Ebook — Racing to the Bottom and Back

When I first published my LLM training book, I priced it at $29. That felt right based on comparable technical ebooks. O'Reilly books run $40-60, but those have a brand behind them. Manning and Pragmatic Programmers charge $30-50. I figured $29 was competitive.

Month 1 at $29: 23 sales. Revenue: $667.

Not bad for a self-published technical ebook with minimal marketing. But then I did something stupid: I read a bunch of posts about how lower prices drive higher volume. The classic indie hacker wisdom of "price low, sell volume."

Month 2 at $19: 31 sales. Revenue: $589.

More sales, less money. The 35% increase in unit sales didn't compensate for the 34% price drop. Classic trap.

I got curious and went the other direction.

Month 3 at $39: 18 sales. Revenue: $702.

Fewer sales, more money. And here's what surprised me: the refund rate dropped. At $19, I had 4 refund requests out of 31 sales (13%). At $39, I had 1 refund out of 18 sales (5.5%). The higher price attracted more serious buyers who actually read the book and found value in it.

Month 4 at $49: 14 sales. Revenue: $686.

Roughly the same revenue as $39, but with fewer customers to support. Emails asking basic questions dropped significantly. The buyers at $49 were developers who already understood the fundamentals and wanted the advanced material — exactly my target audience.

Current price: $44. I settled here after testing $39, $44, $49, and $54 over several months. The revenue curve peaked around $44 for my audience and traffic level.

Here's the data in a table:

| Price | Avg Monthly Sales | Avg Monthly Revenue | Refund Rate | Support Emails/Month | |-------|------------------|--------------------|----|-----| | $19 | 31 | $589 | 13% | 12 | | $29 | 23 | $667 | 9% | 8 | | $39 | 18 | $702 | 5.5% | 4 | | $44 | 16 | $704 | 4% | 3 | | $49 | 14 | $686 | 5.5% | 2 | | $54 | 9 | $486 | 3% | 1 |

The sweet spot was $44. But here's the thing I want to emphasize: the difference between $29 and $44 was only $37/month in revenue. The real win was fewer support emails and higher-quality customers. That's hard to quantify but enormously valuable when you're a solo operator.

---

Product 2: The API — Why Usage-Based Pricing Almost Killed My Launch

AutoDetective.ai's API was a different beast. I was selling to businesses, not individual developers. The standard advice for API pricing is usage-based: charge per request, per lookup, per whatever unit makes sense.

So I launched with usage-based pricing:

• Free tier: 100 lookups/month
• Basic: $0.05 per lookup (no minimum)
• Pro: $0.03 per lookup (minimum $50/month)

The result was catastrophic. Not in the "nobody signed up" way — people signed up. But nobody used it.

In the first month, I had 14 signups for the Basic tier. Total API calls across all 14 accounts: 247. Total revenue: $12.35.

The problem was predictable in hindsight: usage-based pricing creates anxiety. Every API call costs money, so users minimize their calls. They build caching layers on top of my API. They batch requests and process them offline. They do everything they can to avoid hitting my endpoint.

For a product where the value increases with usage — more lookups means better diagnostic coverage for their customers — this was exactly backwards. I was incentivizing people to use my product as little as possible.

I scrapped usage-based pricing after six weeks and switched to flat monthly tiers:

• Starter: $29/month — 500 lookups
• Professional: $79/month — 2,000 lookups
• Shop: $149/month — 10,000 lookups
• Enterprise: Custom pricing

The change was immediate. Same users, dramatically different behavior.

// Simple middleware to track tier usage
var tierLimits = {
  "starter": 500,
  "professional": 2000,
  "shop": 10000,
  "enterprise": Infinity
};

function checkUsage(req, res, next) {
  var apiKey = req.headers["x-api-key"];

  getAccountByKey(apiKey, function(err, account) {
    if (err || !account) {
      return res.status(401).json({ error: "Invalid API key" });
    }

    var limit = tierLimits[account.tier];
    var currentMonth = new Date().toISOString().slice(0, 7);

    getMonthlyUsage(account.id, currentMonth, function(err, usage) {
      if (err) {
        return res.status(500).json({ error: "Usage check failed" });
      }

      if (usage >= limit) {
        return res.status(429).json({
          error: "Monthly limit reached",
          usage: usage,
          limit: limit,
          upgrade_url: "https://autodetective.ai/api/pricing"
        });
      }

      req.account = account;
      req.usage = usage;
      next();
    });
  });
}

Within two months of the switch, monthly API revenue went from that embarrassing $12.35 to $1,247. Same product. Same users (mostly). Completely different pricing structure.

The Professional tier at $79/month became the most popular. Users at that tier averaged about 800 lookups per month — well under their 2,000 limit. They were paying $79 for ~$40 worth of usage under the old pricing, and they were happy about it. Why? Because they could budget for a fixed monthly cost and use the API without thinking about it.

---

Product 3: The Job Board — Free vs. Paid and the Chicken-and-Egg Problem

The Grizzly Peak job board was the trickiest pricing experiment because of the classic marketplace chicken-and-egg problem. You need listings to attract job seekers, and you need job seekers to attract companies willing to pay for listings.

My initial approach was entirely free. Pull jobs from aggregator APIs (RemoteOK, Remotive, Arbeitnow), classify them with Claude Haiku, and display them. This worked for building traffic — we hit about 15,000 monthly job page views within three months.

Then I tried to monetize with a premium listing tier:

Version 1: $99/month for a featured listing.

Results after 60 days: zero paying customers. Not one. I reached out to a dozen companies whose jobs were already listed (via the free aggregator feeds) and offered them the premium tier. The response was universally: "Why would I pay you when our listing is already showing up for free?"

Fair point.

Version 2: $49/month for featured placement + company profile page + 60-day listing.

I also removed the free aggregated listings for companies that had their own career pages (keeping only jobs from companies that actively post to the aggregator APIs).

Results after 60 days: 3 paying customers. Revenue: $147/month.

Better, but not exactly a business. The problem was acquisition cost. I was spending 2-3 hours per customer on outreach, demos, and onboarding. At $49/month, I'd need each customer to stay for at least 4 months to justify the acquisition effort.

Version 3 (current): $29/month for basic featured listing, $79/month for premium with analytics.

I also added a self-serve signup flow so companies could list without talking to me:

var stripe = require("stripe")(process.env.STRIPE_SECRET_KEY);

router.post("/api/subscribe", function(req, res) {
  var email = req.body.email;
  var tier = req.body.tier;

  var priceIds = {
    "basic": "price_basic_monthly_29",
    "premium": "price_premium_monthly_79"
  };

  var priceId = priceIds[tier];
  if (!priceId) {
    return res.status(400).json({ error: "Invalid tier" });
  }

  stripe.checkout.sessions.create({
    mode: "subscription",
    payment_method_types: ["card"],
    customer_email: email,
    line_items: [{ price: priceId, quantity: 1 }],
    success_url: process.env.BASE_URL + "/jobs/admin/welcome?session_id={CHECKOUT_SESSION_ID}",
    cancel_url: process.env.BASE_URL + "/jobs/pricing"
  })
  .then(function(session) {
    res.json({ checkout_url: session.url });
  })
  .catch(function(err) {
    console.error("Stripe error:", err);
    res.status(500).json({ error: "Payment setup failed" });
  });
});

Results after 90 days: 8 paying customers (5 basic, 3 premium). Monthly revenue: $382.

The self-serve flow was the key unlock. Three of those eight customers signed up at 2 AM or on weekends — times when I would never have been available for a sales call. Reducing friction matters more than optimizing price.

---

The Meta-Lessons

After a year of deliberate pricing experiments across three products, here's what I've internalized:

1. Price Higher Than You Think, Then Test Down

Every indie developer I know (myself included) underprices their first launch. We anchor to what we'd pay as consumers, not what the product is worth to the buyer. My ebook experiment proved that $44 was better than $29 in almost every dimension — revenue, customer quality, support burden.

Start at a price that makes you slightly uncomfortable and see what happens. You can always lower it. Raising prices after launch is psychologically harder and risks alienating early customers.

2. Usage-Based Pricing Is a Trap for Most Indie Products

This is controversial, and I know the counterexamples (AWS, Twilio, etc.). But those companies have massive sales teams and enterprise contracts that guarantee minimum spend. For indie products selling to small businesses, usage-based pricing creates anxiety and suppresses usage. Flat tiers with generous limits work better.

The mental model shift: you're not selling API calls. You're selling peace of mind. "For $79/month, you can use our API without thinking about it." That's a fundamentally different value proposition than "$0.03 per call, and here's your meter running."

3. Self-Serve Always Beats Sales Calls at the Indie Scale

I wasted hours on sales calls for the job board. Three hours of outreach and demos to land a $49/month customer is a terrible use of time. The moment I built a Stripe Checkout flow and let people sign up without talking to me, acquisition costs dropped to nearly zero.

This doesn't mean you shouldn't talk to customers. You should. But for initial conversion, get out of the way. Let people give you money at 2 AM on a Saturday if that's when they're ready.

4. Anchoring Is Real and You Should Use It

When I added the $79 premium tier to the job board, it made the $29 basic tier look like a bargain. Three of my five basic-tier customers told me they chose basic "for now" with plans to upgrade — which means they evaluated the premium tier and used it as an anchor.

Similarly, for the ebook, showing the $54 price as a "launch price" option (crossed out) next to the $44 current price increased conversions by about 15%. I know anchoring is Psychology 101. Knowing it and using it are different things.

5. Refund Rates Tell You More Than Conversion Rates

My ebook refund rate dropped from 13% at $19 to 4% at $44. That's not just about money — it's a signal about product-market fit. High refund rates at low prices mean people are impulse-buying and finding the product doesn't match their expectations. Low refund rates at higher prices mean your buyers know what they want and your product delivers it.

If your refund rate is high, the problem isn't your price. It's your positioning.

---

The Numbers That Matter

Here's where everything stands as of February 2026:

| Product | Monthly Revenue | Monthly Profit | Hours/Month to Maintain | |---------|----------------|---------------|------------------------| | LLM Training Book ($44) | ~$704 | ~$680 | 2 | | AutoDetective API (tiered) | ~$1,247 | ~$1,100 | 8 | | Job Board Listings (tiered) | ~$382 | ~$350 | 4 | | Total | $2,333 | $2,130 | 14 |

That's not quit-your-job money, especially in Alaska where heating bills alone can hit $400/month in January. But it's meaningful recurring revenue from products I built and priced through systematic experimentation rather than guesswork.

The most important number in that table isn't the revenue — it's the 14 hours per month. These products run mostly on autopilot now. The pricing experiments are what got them there. Underpricing meant more customers, more support, more time spent on $19 refund requests. Right-pricing meant fewer, better customers who need less hand-holding.

---

What I'm Testing Next

I'm not done experimenting. Here's what's on my list for Q2 2026:

Annual pricing for the API. Offering a 20% discount for annual prepayment. The math says even a 30% discount is worth it for the cash flow certainty and reduced churn.

Bundle pricing. Packaging the ebook with a video workshop. My hypothesis is that a $99 bundle will convert better than the $44 ebook alone, even though the video content costs me time to produce.

Geographic pricing. Showing lower prices to visitors from countries with lower purchasing power. This is ethically murky and technically annoying (VPNs make IP-based detection unreliable), but the potential to capture sales I'm currently losing is significant.

I'll write about those experiments when I have data. Speculation without numbers is just blogging.

---

The One Thing I'd Tell Every Indie Developer

If you take nothing else from this article, take this: run the experiment.

Don't agonize over pricing in a spreadsheet. Don't poll your Twitter followers. Don't read eight more blog posts about pricing strategy (including this one). Pick a price, launch, measure for 30 days, change the price, measure for 30 more days.

Pricing is empirical, not theoretical. The market will tell you what your product is worth, but only if you're willing to ask by actually changing the number and watching what happens. I wasted months overthinking my ebook price before I started testing. The testing itself took 30 days and gave me more insight than all the thinking combined.

Your time is better spent on a quick experiment with real customers than on a perfect pricing strategy that exists only in your head.

Shane Larson is a software engineer and technical author based in Caswell Lakes, Alaska. He builds products at Grizzly Peak Software and AutoDetective.ai, and he's still not sure if $44 is the right price for anything. Find more at grizzlypeaksoftware.com.