The Pricing Mistake Every Developer Makes
You've built something. Now you need to put a number on it. So you do one of two things: you calculate how many hours it took and multiply by your hourly rate, or you look at what similar tools charge and pick something in the same range. Both feel logical. Both are wrong.
Mistake 1: Pricing on Cost or Time
"I spent 400 hours on this, so at $50/hour that's $20,000 worth of work — I'll charge $97." This is called cost-plus pricing, and it's how you build a product and fail to sell it. Your cost is irrelevant to your customer. They don't care how long it took you to build. They care about one thing: what it does for them.
Cost-plus pricing also systematically undercharges. A tool that saves an engineer 5 hours a week is worth thousands of dollars per year to a company — regardless of whether it took you a weekend or three months to build. If you price it at $29/month because "that seems fair for my effort," you're leaving most of that value on the table.
// The cost-plus pricing trap
cost_of_building = 400h × $50/hr = $20,000
price = $97 // "seems fair"
// What you should ask instead:
value_to_customer = 5h/week × 50 weeks × $80/hr = $20,000/yr
price = ??? // suddenly $97/yr looks very low
Mistake 2: Copying Competitors Without Understanding Why
Looking at what competitors charge is useful data — but treating it as a constraint is dangerous. Competitors made their pricing decisions with their own cost structure, their own customer acquisition model, their own growth stage, and their own mistakes baked in. Copying them means inheriting all of that, blindly.
More importantly: if you price identically to an established competitor, you're signalling to the market that you're the same product. You're not. Use competitor pricing as a reference point, not a ceiling.
Competitive pricing is a starting point, not an answer
Use competitor prices to understand market expectations and what customers are already comfortable paying. Then ask: what makes my product worth more? Or: why would someone pay less for mine? Position and price accordingly.
The Correct Framework: Price on Value Delivered
Value-based pricing starts with a single question: what is it worth to the customer for this problem to be solved? The answer comes in three forms:
Time saved
If your tool saves a developer 3 hours a week, that's 150 hours a year. At a $60/hr effective rate, that's $9,000 in recovered time. Your tool is worth a substantial fraction of that — conservatively 10-20%, or $900-$1,800/year. If you're charging $19/month ($228/year), you're pricing at 2.5% of the value you deliver.
Revenue generated
If your landing page template helps a developer's SaaS convert 2x better, and that SaaS earns $5,000/month, your template directly contributed to thousands of dollars in additional revenue. Charge accordingly. $197 or $297 is trivial compared to the outcome.
Pain eliminated
Some pain is so frustrating that people pay just to never deal with it again — even if the time cost is hard to quantify. Authentication, billing, deployment, error monitoring: developers will pay a premium to have these things "just work." The emotional value of removing friction is real and should be priced into your product.
Before You Set Any Price, Answer These Questions
1. What would it cost the customer to solve this problem without my product?
2. How many hours per week does my product save them?
3. What is the dollar impact of the outcome my product produces?
4. What are customers currently paying for an inferior alternative?
5. Who is my ideal customer — an indie dev or a funded startup?
The Four Pricing Models for Dev Products
Pricing model and price point are two separate decisions. The model determines how customers pay — one time, recurring, or metered. Get the model wrong and no price point will save you. Here are the four models used by successful indie dev products, with clear guidance on when each one fits.
One-Time Purchase
The customer pays once and owns the product forever. Simple, clean, no retention pressure. Best suited to products that deliver a discrete, self-contained value: a template, a script, a code generator, a boilerplate, or a lifetime deal on a tool that requires minimal ongoing infrastructure.
Pros
- +Low friction to buy — no ongoing commitment
- +Revenue spikes are large and satisfying
- +No churn to manage after purchase
- +Simple to operate — no billing infrastructure needed
Cons
- –Revenue requires constant new customer acquisition
- –No predictable monthly income
- –Buyers expect free updates forever (set boundaries)
- –Hard to sustain ongoing development investment
// When to use it
product.type == "template" || "boilerplate" || "starter kit"
product.hosting == false // no servers to maintain
product.updates == "occasional" // not daily feature dev
typical_range == "$49 – $497"
Real examples: SaaS boilerplate kits ($199–$399), Figma UI kits ($49–$149), Next.js starter templates ($79–$299), Notion templates ($19–$99)
Monthly Subscription (SaaS)
The customer pays a fixed amount every month for ongoing access. This is the gold standard model for tools that deliver continuous value — monitoring, email sending, analytics, automation, CMS access, or any product where the value compounds over time. Subscription revenue is predictable and compounds, making it the highest-value business model for indie developers who want a sustainable income.
Pros
- +Predictable, compounding MRR
- +Revenue continues without new sales
- +Justifies ongoing product investment
- +Annual plans create cash flow upfront
Cons
- –Churn is a constant threat — customers must keep renewing
- –Higher friction to sign up than one-time
- –Requires support, uptime, billing infrastructure
- –Slow ramp-up — MRR grows gradually
// When to use it
product.delivers_ongoing_value == true
product.requires_hosting == true // you run servers
product.updates == "continuous"
typical_range == "$9 – $99/mo" // indie tier
Real examples: API monitoring tools ($12–$49/mo), email platforms ($9–$79/mo), CI/CD tools ($19–$99/mo), developer dashboards ($15–$49/mo)
Usage-Based (Per-Seat, Per-API-Call, Per-Action)
The customer pays based on how much they use: API calls made, emails sent, seats added, reports generated, or GB of storage consumed. Usage-based pricing is increasingly popular for developer tools because it aligns cost with value perfectly — small customers pay small amounts, large customers pay proportionally more. It also removes the "is this worth it?" conversion barrier, since there's no upfront commitment.
Pros
- +Revenue scales automatically with customer success
- +Lowest friction to start — "pay as you go"
- +Enterprise customers expand naturally
- +Fair — customers only pay for what they use
Cons
- –Revenue is unpredictable month-to-month
- –Billing infrastructure is complex to build
- –Customers may throttle usage to control costs
- –Difficult to forecast and budget for customers
// When to use it
product.type == "API" || "infrastructure" || "per-seat-tool"
product.usage_measurable == true // clear unit of value
product.customers == "range from tiny to enterprise"
typical_range == "$0.001/call – $0.10/action"
Real examples: SMS/email APIs ($0.001–$0.01/message), AI APIs ($0.001/token), observability tools ($0.10/GB ingested), translation APIs (per character)
Freemium
A permanently free tier exists alongside paid plans. Freemium isn't a business model — it's a distribution strategy. The free tier is a top-of-funnel acquisition channel. The trap is building a free tier that's so good nobody upgrades. The correct design: the free tier should demonstrate your product's value clearly, while hitting a natural ceiling that makes upgrading feel like the obvious next step.
Pros
- +Massive top-of-funnel — users try before they buy
- +Word-of-mouth grows naturally with free users
- +Establishes product usage habit before asking for money
Cons
- –Free users are costly to support and host
- –Typical conversion rate: 2–5% of free to paid
- –Wrong free tier design kills upgrade incentive
- –Requires significant scale to work financially
// Freemium free tier design rule
free_tier.must_demonstrate_core_value = true
free_tier.must_hit_natural_upgrade_wall = true
free_tier.must_be_sustainable_to_host = true
free_tier.upgrade_trigger = "usage limit" || "team feature" || "advanced capability"
Which Model Fits Your Product?
Does your product require ongoing hosting and continuous development?
→ YES: Subscription or Usage-based
Does value scale with usage volume? → Usage-based. Fixed value regardless of volume? → Subscription.
Is it a discrete artifact (template, script, boilerplate) with no hosting cost?
→ YES: One-time purchase
One-time purchase can be supplemented with an annual "updates + support" plan.
Do you need a large user base for word-of-mouth and have low per-user hosting cost?
→ YES: Freemium + Subscription upgrade
Only works if you can profitably serve free users. Typical: analytics, note tools, lightweight SaaS.
Not sure? Start here:
→ One-time purchase to validate, then add subscription for ongoing features
The Psychology of Price Points
Pricing is not purely rational. The same product at $50 and $49 converts differently — not because of the dollar saved, but because of how the brain processes numbers. Understanding these effects won't substitute for getting your value proposition right, but it will squeeze meaningful additional revenue from the same traffic once the fundamentals are solid.
Why $49 Beats $50 (And When It Doesn't)
Charm pricing — ending a price in 9 — exploits the way the brain reads left-to-right. $49 is processed as "40-something" before the 9 registers. $50 reads immediately as "fifty." The mental distance feels larger than a dollar. This effect is well-documented and works across currencies and cultures.
However: charm pricing signals value, not premium. If you're positioning as a premium, high-end product, round numbers ($100, $200, $500) actually perform better. Apple charges $999 for products despite the charm number being $999, and charges $1,200 for Macs instead of $1,199 — because at a certain price point, round numbers signal quality and confidence. Use charm pricing for sub-$500 products targeting value-conscious buyers; use round numbers when you're positioning as premium.
// Charm pricing vs round number guidelines
value_positioning → $49, $97, $197, $297, $497
premium_positioning → $50, $100, $200, $500
// The $X7 pattern
$17, $27, $47, $97, $197 — common in info products
// Anecdotally outperforms $X9 for digital products in some markets
Price Anchoring
Anchoring is when you show a high reference price first to make your actual price feel like a better deal. Every pricing page that shows an annual plan next to a monthly plan is using anchoring — the monthly price is the anchor that makes the annual price look like a bargain.
// Anchor examples
Original price crossed out:
$97/mo → $49/mo // 50% off launches feel more valuable
Annual vs monthly comparison:
$49/mo vs $39/mo billed annually // monthly is the anchor
Show value delivered first:
"Worth $X in saved time" → "Costs just $Y/mo"
The Rule of Three Pricing Tiers
Three pricing tiers is the optimal number for conversion. Two tiers force a binary choice and often result in most customers choosing the cheaper option. Four or more tiers cause decision paralysis. Three tiers do something elegant: they create a reference frame that makes the middle tier feel like the intelligent choice.
// The classic three-tier structure
tier_1: Basic / Starter → "for individuals just getting started"
tier_2: Pro / Growth → "most popular" ← highlight this one
tier_3: Enterprise / Scale → "for teams and high volume"
// Price ratio guidance
tier_1 : tier_2 : tier_3 = 1 : 2.5 : 8
example: $15/mo : $39/mo : $99/mo
Always highlight the middle tier. Add a "Most Popular" or "Best Value" badge. Use a visually prominent border or background color. Research consistently shows that the highlighted tier captures 50–70% of all signups. If you want to maximize MRR, make the Pro tier the one you highlight and ensure it has enough features to justify the price over the Basic tier.
Decoy Pricing
A decoy option is a pricing tier that isn't meant to be chosen — it exists to make another tier look better by comparison. The classic example: a small popcorn for $3 and a large for $7 converts poorly. Add a medium for $6.50, and suddenly the large looks like a deal. The medium is the decoy.
In dev products, decoy pricing often looks like this: a Basic tier that's deliberately limited (useful for tiny use cases), a Pro tier that's excellent value, and an Enterprise tier that's priced high enough to make Pro look like a steal. The Basic tier can also serve as a decoy — if it's priced close to Pro but offers significantly less, most buyers go straight to Pro.
// Decoy in action
basic: $19/mo → 3 projects, 1 user // decoy: not enough for most real use
pro: $29/mo → unlimited, 5 users // ← the real target
enterprise: $99/mo → unlimited, 20 users // anchor: makes Pro look affordable
// Result: Basic makes Pro feel like a deal. Enterprise makes Pro feel accessible.
"The best pricing pages don't make people choose. They make one option feel obviously correct. If someone has to think hard about which tier to pick, your tiers are too close together or your feature differentiation isn't clear enough."
Real Pricing Examples from Indie Dev Products
Theory is useful. Seeing it applied is better. Here are five pricing strategies from real indie developer products, described generically — you'll recognise the patterns even without names. In each case: what they got right, what you can steal, and what to avoid copying.
The SaaS Boilerplate — One-Time + Lifetime Access
Think: Next.js/Astro starter kit, Stripe + auth pre-wired, one payment
Pricing structure: one tier at $199 (solo) and $299 (commercial), with occasional launch discounts. No subscription. Full source code access on purchase, all future updates included.
What They Get Right
- ✓Binary, frictionless decision. No plan comparison — one product, one price. The buyer just decides yes or no. Removes all cognitive load.
- ✓Revenue social proof on the pricing page. Showing "$X earned from products built with this" turns a tool purchase into a revenue investment. The ROI argument is made before the buyer even has to ask.
- ✓Commercial license upsell. The $100 jump from solo to commercial is high-margin and self-selecting — businesses pay it without blinking.
The Developer Tool SaaS — Three Tiers, Annual Default
Think: lightweight monitoring, logging, or analytics tool built by one developer
Pricing structure: Starter $9/mo, Pro $29/mo (highlighted), Team $79/mo. Annual toggle shown by default (2 months free). 14-day free trial, no credit card required.
What They Get Right
- ✓Annual plan shown by default. Pricing page loads with the annual view active, not monthly. This means most visitors compare annual prices, which look cheaper — and many don't switch to monthly at all.
- ✓No-card trial. Removes the biggest objection for developer tools: "I'll just forget to cancel." Zero commitment = higher trial-start rate.
- ✓Clear feature differentiation. The limit that triggers Starter → Pro upgrade is obvious (e.g., data retention, team members, API calls). There's no ambiguity about when to upgrade.
The API Product — Usage-Based with a Free Tier
Think: small AI/NLP/image processing API built by an indie developer
Pricing structure: Free ($0 — 1,000 calls/month), Pay-as-you-go ($0.002/call above free tier), Pro ($29/mo — 50,000 calls included, then $0.001/call overage).
What They Get Right
- ✓Free tier as distribution. The free 1,000 calls lets developers integrate the API into projects before paying. By the time they hit the limit, it's already in production — switching cost is high.
- ✓Natural upgrade motivation. A developer who hits 1,000 calls has a working integration. The Pro tier's economics are obviously better at any meaningful usage volume. The math does the selling.
The Course / Cohort — Tiered One-Time with Bonuses
Think: developer marketing or growth course sold in cohort batches
Pricing structure: Self-paced $197, Community $397 (+ Discord access + office hours), VIP $797 (+ 1:1 session + done-with-you implementation). Launch window pricing with a visible deadline.
What They Get Right
- ✓Access + community as the upgrade driver. The base product delivers value. The upgrade isn't "more content" — it's accountability, community, and direct access. These are high-perceived-value, low-marginal-cost additions.
- ✓VIP tier that's worth it. A 1:1 session that costs $100 to deliver can justify a $400 price difference. VIP buyers self-select as high-value customers who are serious about outcomes.
The No-Code / Visual Tool — Freemium SaaS Done Right
Think: form builder, link-in-bio, or lightweight CMS built by one developer
Pricing structure: Free (3 projects, branding on outputs), Pro $12/mo (unlimited projects, no branding, custom domain), Business $39/mo (team, analytics, priority support).
What They Get Right
- ✓Branding removal as the primary upgrade. Free users spread awareness via "Made with [Product]" on outputs. Pro removes it. This is a masterclass: free tier is a marketing channel, and the upgrade has a concrete, professional-feeling reason to pay.
- ✓$12/mo is a no-brainer price. For a professional-grade tool, $12 is below the mental threshold of serious scrutiny. The decision is basically "do I want to look professional?" — and the answer is always yes for paying customers.
Common Pricing Page Mistakes to Avoid
Too many tiers
Five tiers feels comprehensive but causes analysis paralysis. Visitors scroll, compare, second-guess, and leave. Three tiers is the ceiling. If you have more to offer, use add-ons or enterprise "contact us" instead of adding more columns.
Hiding the price
"Contact us for pricing" means every qualified buyer has to jump through a hoop before knowing if your product is in their budget. Developer-buyers will go to a competitor with transparent pricing rather than book a demo. Show the number.
No annual option
If you only offer monthly, you're leaving 15-30% revenue on the table and missing the cash flow benefit of annual upfront payments. Always offer annual at approximately a 2-month discount (16-17% off). Some buyers will choose annual simply because they dislike recurring charges — give them the option.
How to Raise Your Prices Without Losing Customers
Most indie developers are underpriced. They launched at a low price to reduce friction, validated that the product works, and never revisited the number. Raising prices is uncomfortable — it feels like you're being greedy, or that customers will leave. In practice, done correctly, a price increase increases both revenue and customer quality.
Signs You're Underpriced
Your conversion rate is unusually high. If 15%+ of trial users convert to paid, your price is too low. A good product at the right price converts 3–8%. High conversion at low price means you have pricing headroom.
Nobody objects to the price. If you never hear "that's a bit expensive" or "can I get a discount?", you're priced below market sensitivity. Some price objections are healthy — they mean you're at the upper edge of what the market will pay.
Customers rave about the value. "This is incredible for the price" or "I can't believe how cheap this is" are direct signals that perceived value far exceeds your price. Customers telling you you're underpriced is about as clear a signal as you'll get.
Your churn is very low. If customers are staying for 12+ months without prompting, the product is deeply embedded in their workflow. That stickiness gives you pricing power — embedded customers absorb price increases with far less churn than new customers would.
The Grandfathering Strategy
When you raise prices, honour existing customers' current rate permanently (or for a defined period, such as 12 months). This is called grandfathering, and it turns a potentially negative event — a price increase — into a positive experience for existing customers. "You're locked in at your current rate forever" is a loyalty reward, not a concession.
// Grandfathering announcement template
Subject: "Your [Product] price is changing — but not for you"
---
Hey [Name],
We're raising [Product] prices for new customers on [Date]. New customers will pay $[new_price]/mo.
As an existing customer, you're locked in at $[current_price]/mo — forever, as a thank-you for being an early supporter.
Nothing changes on your end. Your next billing date is unaffected.
Thank you for building with us.
Framing a Price Increase as an Upgrade
If you can't grandfather everyone, frame the price increase as a product improvement. Coincide the increase with a significant new feature or capability: "We're launching [Feature X] and moving to a new pricing structure that reflects the expanded value." Customers who are getting more are far more willing to pay more — even if the feature they're getting wasn't something they asked for.
Give at least 30 days notice before any price increase takes effect
Offer existing customers the option to pre-pay at the old rate for up to 12 months — converts cash and reduces churn simultaneously
Communicate the increase personally (email, not just an in-app banner)
Thank customers for being early supporters — acknowledge that their early commitment helped you build what the product is today
Testing Price Increases with New Visitors Only
Before committing to a price increase for everyone, test it on new visitors. The simplest approach: change your pricing page to the new price and measure conversion rate for 2-4 weeks against your historical baseline. If the conversion rate drops by less than the percentage increase in price, your revenue goes up even with fewer conversions.
// Price increase math
old_price = $29/mo
new_price = $49/mo // +69% price increase
breakeven_rule = conversion_drop must be < 41%
// Example
old: 100 visitors × 4% CVR × $29 = $116 revenue
new: 100 visitors × 3% CVR × $49 = $147 revenue // +27% revenue despite lower CVR
"The customers who leave because of a price increase are usually your highest-churn, lowest-value customers anyway. The customers who stay are the ones who've built your product into their workflow. A price increase is a natural filter — it retains your best customers and pushes out the marginal ones."
Pricing Page Design Principles
A well-designed pricing page doesn't just display prices — it guides visitors to the right tier, eliminates purchase anxiety, and makes the decision feel easy. Most developer-built pricing pages fail not on the numbers but on the design and copywriting around the numbers.
Annual vs. Monthly Toggle
Always offer annual billing. The standard offer is "2 months free" when you pay annually, which equates to a 16.7% discount. This works because:
You get 12 months of cash upfront — dramatically better for your cash flow and growth reinvestment
Annual customers churn 3-5x less than monthly customers — they've made a bigger commitment and feel more invested
Some buyers prefer annual purely because they dislike seeing a recurring monthly charge on their card — you're removing a friction point for them
// Annual toggle implementation tips
default_view = "annual" // show annual first — most products do this
annual_badge = "2 months free" || "Save 17%" // make the discount visible
annual_display = "$X/mo" // show monthly equivalent even for annual
annual_subtext = "billed annually as $[total]" // be transparent
Feature Comparison Tables
A feature comparison table is the clearest way to communicate what's different between tiers — but most developers build tables that are too long, too granular, and full of features the customer doesn't care about. Follow these rules:
Show the upgrade trigger prominently
The most important rows are the ones that differ between tiers. Rows that are identical ("SSL certificate: ✓ ✓ ✓") add visual clutter without helping the decision. Bold or highlight the rows that change.
Cap the table at 8-10 rows
If you have 30 features, group them into categories and show the most important ones. A table that requires scrolling loses visitors. Keep it scannable — people read feature tables in 10 seconds, not 2 minutes.
Use numbers, not just checkmarks
"Projects: 3 / 10 / Unlimited" is more informative than "✗ / ✓ / ✓". Numbers make the upgrade decision concrete: "I need more than 3, so I need Pro."
The Money-Back Guarantee
A money-back guarantee consistently increases conversion by more than it increases refunds. The data is clear: most customers who buy with a guarantee never use it — but having the option removes the risk that was stopping them from buying.
30 days is the industry standard. Put it directly on the pricing page — not buried in the ToS, but next to the CTA button or as a visible trust badge. The copy matters: "30-day money-back guarantee, no questions asked" converts better than "refunds available within 30 days per our terms." The former is a promise; the latter sounds like a legal caveat.
// Guarantee placement and copy
placement = "below CTA button" // right at the point of decision
"30-day money-back guarantee. No questions asked."
"Try risk-free for 30 days. If it's not right for you, we'll refund every penny."
// What NOT to write:
"Refunds processed per our Terms of Service (Section 7.2)"
CTA Copy for Pricing Pages
The same principles from landing page CTAs apply here — but pricing page CTAs have a unique challenge: they need to overcome the immediate price objection the visitor just experienced. Your CTA must feel like the next logical step, not a financial commitment.
For free trials:
"Start Free Trial — No Card Needed"
For one-time purchases:
"Get Instant Access →"
For monthly subscriptions:
"Start Building — Cancel Anytime"
For annual plans:
"Get [N] Months Free — Start Now"
With guarantee:
"Try Risk-Free for 30 Days"
Avoid:
"Subscribe" / "Purchase" / "Buy Now"
"The best pricing pages don't look like pricing pages. They look like the natural next step after a great pitch. By the time a visitor reaches your pricing page, the sale is mostly already made — your pricing page just needs to not break the momentum."
Pricing Checklist
Whether you're pricing a new product or reviewing an existing one, run through this list. Every unchecked item is a potential revenue leak.
Pricing Strategy
Tiers & Structure
Page Psychology
Ongoing Review
"Your first price is rarely your best price. Ship it, watch what happens, and iterate. The developers who earn the most from their products treat pricing as a product feature — something to design, test, and improve over time, not set once and forget."
Level Up Your Marketing
Subscribe to the CodeToCash newsletter for weekly playbooks, teardowns, and DRM tactics for developer entrepreneurs.
Building in public. No spam, unsubscribe anytime.