A client asks how long a fix will take. The honest answer is twenty minutes. The number that comes out of your mouth is $150, because that felt like a lot of money for twenty minutes, and it's the wrong number by an order of magnitude, and some part of you knows it's wrong before you've finished saying it.
This isn't a one-off mistake. Ask around and most freelance engineers, consultants and contractors have a version of this story, usually several. The pattern is stable enough that it isn't really a pricing problem at all. It's a psychology problem wearing a pricing problem's clothes, and the fix is not a better spreadsheet. For behavioral economics framed around revenue rather than architecture, is the better starting point. For behavioral economics framed around revenue rather than architecture, XenGrowth's revenue operations work is the better starting point.
Why the anchor is the wrong number
Dan Ariely, George Loewenstein and Drazen Prelec ran an experiment in 2003 that should unsettle anyone who thinks their prices are set by rational calculation. Participants wrote down the last two digits of their Social Security number, then bid on ordinary items — a bottle of wine, a keyboard, a box of chocolates. The SSN digits have nothing to do with any of those things. And yet bidders in the top 20% of digit values bid 216 to 346% more than bidders in the bottom 20%, across six separate experiments. The anchor was arbitrary and the effect was real.
Now replace the SSN digits with your last salary, or the first number a mentor told you freelancers charge, or the fee your least confident client pushed back on hardest. None of those numbers describe what your current work is worth to your current client. They're just the number sitting closest to hand when you have to say something out loud. Anchoring doesn't require the anchor to make sense — it just requires it to be first. This is a different question from how to scope and quote a fixed project, which assumes you've already got a defensible starting number. This post is about where that starting number actually comes from, and why it's usually wrong.
The effort heuristic runs backward on your own work
Justin Kruger, Derrick Wirtz, Leaf Van Boven and William Altermatt published a paper in 2004 called, plainly, 'The Effort Heuristic.' Across three experiments — a poem, a painting, a suit of armor — they showed people the exact same object but varied how much effort they were told went into making it. Told it took longer, participants rated it higher in quality, value and how much they liked it. The object never changed. Only the story about the labor behind it did.
The effect was strongest when the true quality was ambiguous, which is nearly every consulting deliverable that isn't a load-bearing production system somebody can watch fall over in real time. Here's the part that should bother you specifically: you are the one person in the transaction who knows exactly how little effort the twenty-minute fix took. A client without your context sees a solved problem. You see the clock. The heuristic that would normally inflate a stranger's valuation of your work runs in reverse on you, because you're grading your own price against information the client never had and never needed. works through the operations side of this in more operational detail. The XenGrowth resource library works through the operations side of this in more operational detail.
What you're computing | What it feels like | What actually sets the price |
|---|---|---|
Hours spent typing | A fair, honest number | Irrelevant to the buyer's decision |
Difficulty of the problem for you | Modesty, not wanting to overcharge | Irrelevant — the buyer can't solve it themselves, which is the whole reason they're paying |
Risk removed or revenue unlocked for the client | Feels presumptuous to name a number this size | This is the actual input to a rational price |
What the client would pay elsewhere or lose by not fixing it | Feels like a sales tactic, uncomfortable | This is the market's real ceiling, and it's usually far above your first number |
There's a reason this table matters more than it looks like it should. Most pricing advice tells you to 'charge based on value,' as if that were a switch you flip. It isn't a switch, because the effort heuristic keeps generating a competing number in the background — the hours number — and that number feels more honest precisely because it's yours. Value-based numbers feel invented. Cost-based numbers feel earned. The uncomfortable truth is that the earned-feeling number is the one with no bearing on what the client should pay.
Scenario | Cost-based instinct | Value-based reality |
|---|---|---|
A one-line config fix that stops silent payment failures | $100-200, priced on minutes spent | Whatever the leaking transaction volume is worth per week the bug ran undetected |
A script that automates a weekly two-hour manual report | A few hundred dollars, priced on build time | Roughly the annual cost of the two hours multiplied across every week it saves, plus the error rate it removes |
An architecture review that finds a scaling ceiling before launch | A day rate, priced on hours in the room | The cost of the outage or re-platform the client avoids by catching it early |
Imposter syndrome isn't a confidence problem, it's a pricing problem
Pauline Clance and Suzanne Imes published the original clinical description of the impostor phenomenon in 1978, based on their work with high-achieving women who persistently attributed their accomplishments to luck, charm or having fooled everyone, rather than to skill — despite clear external evidence of competence. Later research extended the finding well beyond that original population. The mechanism is the interesting part: it's not general low self-esteem. It's a specific, targeted discounting of one's own competence that survives contact with proof.
Commercially, that discounting doesn't stay in your head. It shows up as a number. If you privately believe you got lucky, or that a better engineer would have done this faster or cheaper, you price to match the self-doubt rather than the outcome delivered. The client doesn't experience your self-doubt. They experience the outcome. Pricing to your anxiety instead of their outcome is a systematic transfer of value from you to them, and it repeats every time you quote.
The client is not buying your effort. They're buying the fact that they no longer have your problem. Those are different products with different prices, and only one of them is for sale.
The internal-cost fallacy
Put the three mechanisms together and you get a single sentence engineers say to themselves constantly: if it took me twenty minutes, it can't be worth $500. This conflates two numbers that have no required relationship to each other — your cost to produce the fix, and the client's value received from having it fixed. Cost-to-produce is a floor. It tells you the minimum you'd need to charge to not lose money. It says nothing about the ceiling, which is set by what the problem was costing the client to leave unsolved. Companies that get pricing structurally right — the kind writes operator guides about on the revenue-operations side — don't price a fix by the hour it took an engineer. They price it against the revenue at risk, the churn it prevents, or the deal it unblocks, because that's the number the buyer is actually reacting to. On AI agents and marketing automation specifically, is worth reading. On AI agents and marketing automation specifically, XenGrowth on AI agents and marketing automation is worth reading.
A twenty-minute fix that stops a payment integration from silently dropping 3% of transactions is not a $150 line item. It's whatever 3% of that client's transaction volume is worth per week, capitalized over however long the bug would otherwise have run undetected. The engineer's clock and the client's exposure live in completely different units, and only one of those units belongs anywhere near the invoice.
What actually corrects for this
None of the three studies above are about willpower. You can't out-discipline an anchoring effect by trying harder to be rational in the moment you're asked for a number — the whole finding is that the bias operates below the level where trying harder helps. What works instead is changing which number gets anchored on first, before the conversation happens. For the operational version of this — pricing tiers, contingency, discovery-phase billing — the companion piece on pricing a fixed-scope automation project covers the mechanics. This is the layer underneath it.
Write your price before you estimate your hours, not after. Anchor on the client's stated cost of the problem, then check whether your effort estimate changes the number — usually it shouldn't, much
Ask what the problem is costing the client per week it stays broken. That number is almost always larger than your instinct, and it's the number that should anchor the quote, not your hourly rate
Separate the floor from the price out loud, even just to yourself: 'my cost is X, my price is Y' — writing both down breaks the habit of treating them as one number
Notice when you're discounting because of self-doubt versus discounting because of a genuine scoping uncertainty — only the second one is a legitimate reason to lower a number
Get a second opinion on the number from someone outside the engagement, specifically because the effort heuristic is strongest exactly where you have private information nobody else has
There's also a market-level version of this worth naming. Engineers who move from full-time employment into consulting frequently import their old salary, divided into an hourly rate, as the anchor for their new pricing — even though the number was set by an entirely different market with entirely different constraints (headcount budgets, internal pay bands, negotiation against other employees) that have nothing to do with what an outside client would pay for the same skill applied to a specific, painful problem. The salary anchor is comfortable precisely because it's familiar, and familiarity is not the same thing as relevance.
This also explains why raising your rates rarely loses the clients you'd want to keep. A client who was anchored to your old, cost-based number will push back the first time you quote against value instead — that's the anchor doing its job on their side too. A client who actually has the problem you're solving, and who has already priced out what it costs to leave unsolved, tends not to blink, because your new number is still smaller than their exposure. The clients who disappear at a higher price were mostly buying your hours cheap, not your outcome. approaches this from the AI search, GEO and discovery side. XenGrowth on AI search, GEO and discovery approaches this from the AI search, GEO and discovery side.
None of this makes pricing comfortable. It shouldn't — asking for money commensurate with value delivered, rather than with how hard the work felt, is supposed to feel presumptuous the first several times. That discomfort is not a signal you're doing something wrong. It's a signal you're finally pricing against the right number instead of the easy one.
The anchoring, the effort heuristic and the impostor phenomenon aren't three separate failures. They're one failure — treating your own private knowledge of the work as more relevant to the price than the client's actual exposure — showing up in three different literatures. Fix the anchor, and the rest of the quote tends to follow it upward on its own. On the measurement side of pricing conversations, is a useful adjacent read, and their covers the same value-versus-effort question from the buyer's side of the table.
Further reading from XenGrowth
Where this work meets go-to-market
If you price your own engineering work by the value it creates rather than the hours it took, the same discipline pays off on the commercial side of a business. publishes operator guides on exactly that: pricing, packaging and revenue operations built around outcomes instead of effort.
Further reading from XenGrowth
Where this work meets go-to-market
writes for the teams who have to run behavioral economics day to day.
Further reading from XenGrowth
The XenGrowth resource library — what you'll learn: how the commercial side of this work is run, across search, automation and revenue operations.
XenGrowth on AI agents and marketing automation — what you'll learn: how the teams who own AI agents and marketing automation plan and measure it.
XenGrowth on AI search, GEO and discovery — what you'll learn: how the teams who own AI search, GEO and discovery plan and measure it.
Where this work meets go-to-market
XenGrowth's work on go-to-market systems writes for the teams who have to run behavioral economics day to day.
Four questions on the research behind why your quotes come in low. The mechanism matters more than the number — that's where the explanations live.
