In one sentence
Price a software product according to the value it delivers in the real market, not according to how quickly, cheaply, imperfectly, or painfully it was built.
Overview
McKenzie responds to the fear that customers will reject software because it was built quickly or because they could theoretically reproduce it. His central point is that customers buy outcomes and convenience, not an accounting of the creator’s labor. A product’s demand depends on what customers need and what alternatives actually exist—not on the developer’s sunk costs or internal comparison with an idealized version of the product.
Core ideas
Do not volunteer irrelevant production details
If a product was built in a week, that fact usually matters only if the customer knows it and interprets it negatively. Transparency does not require advertising information that has no bearing on whether the product works or creates value.
Customers buy solutions, not implementation effort
The relevant question is not “How long did this take to build?” but “What is this worth to the customer?” A fast implementation can still solve an expensive or urgent problem.
Separate product pricing from hourly billing
Consulting ties revenue to hours worked. A repeatable software product can be sold many times at almost no additional production cost, so its price need not track the creator’s labor per sale.
Price against real alternatives
Customers compare the product with what they can actually do: continue suffering the problem, use an existing competitor, hire someone, or build a replacement. They do not compare it with the developer’s imagined perfect product.
Reimplementation cost can justify a substantial price
Even if a customer could theoretically recreate the software, doing so consumes time, attention, and opportunity. The customer may rationally pay far more than the software’s marginal cost to avoid that work and obtain the result now.
Beware coder’s remorse
Developers see bugs, compromises, unfinished ideas, and implementation shortcuts every day. This familiarity causes them to judge the product against its original vision rather than against competing products that customers can actually buy.
Practical takeaways
- Ask what measurable cost, risk, delay, or inconvenience the product removes for the buyer.
- Experiment with higher prices instead of assuming that affordability is the main reason people buy.
- Do not use development time, sunk investment, or personal dissatisfaction as the primary pricing formula.
- Evaluate the product from the customer’s perspective: what alternatives exist today, and what would solving the problem be worth?
- Be especially cautious about underpricing when the buyer is a nontechnical professional who values convenience and certainty.
- Remember that the argument supports value-based pricing, not unlimited pricing: the product still has to meet the customer’s needs and face whatever real competition exists.
Caveats and counterpoints
- The argument is strongest for differentiated software sold repeatedly, where marginal distribution costs are low. It is less directly applicable to bespoke consulting, labor-intensive implementation, support-heavy services, or products with substantial infrastructure costs.
- McKenzie understates competitive pressure when he says that, absent competition, one can choose any point on the demand curve. In practice, substitutes, budgets, procurement rules, trust, switching costs, and customer price sensitivity all constrain pricing.
- The claim that nonprogrammers will not rebuild a product is directionally useful but too broad. Some customers can use internal staff, no-code tools, spreadsheets, or competitors to approximate the solution.
- High price can signal quality, but it can also reduce adoption, invite scrutiny, or expose weak product-market fit. Raising price is an experiment, not proof that the product is undervalued.
Questions worth revisiting
- What specific customer outcome does this product create, and how could its value be estimated?
- What would the customer do instead if the product did not exist?
- Am I pricing against the product’s actual alternatives or against my own idealized version of it?
- Which imperfections are visible to customers, and which matter only to me as the creator?
- Would a higher price improve positioning, or merely make the product harder to buy?
- How much of the price should reflect onboarding, support, reliability, and risk reduction rather than the software itself?
Return to this when…
Return to this when setting or revising a price, especially if you feel compelled to charge based on hours worked or because the product seems too simple, quick, or imperfect to command a meaningful price.