A client asked me for a "quick rate" over email three years ago, and I typed a number I'd basically made up on the spot, based on nothing more than what felt reasonable for a Tuesday. I got the job. I also spent the next six weeks resenting every hour of it, because the number I'd picked assumed a simple integration and the actual scope turned out to involve migrating a decade of legacy data out of a system nobody had documented. I didn't renegotiate. I just worked longer hours and told myself that's what freelancing meant.
It isn't. I've changed how I price work twice since then, and the current approach is the first one that's actually held up under a messy, real project instead of just looking clean on a spreadsheet.
Hourly rates aren't wrong, they're just answering the wrong question
There's nothing broken about hourly billing as a concept. The problem is what it optimizes for. If I bill hourly, I get paid more the slower I work and less the faster I solve the client's problem, which is backwards from what the client actually wants and backwards from what I want too, since efficient work is the entire reason clients hire an experienced freelancer instead of training a junior in-house. Jonathan Stark has been making this argument for years, and the part that finally landed for me wasn't the theory, it was noticing my own behavior. I caught myself, more than once, taking a slightly longer path through a problem because I knew a faster fix would mean a smaller invoice. That's not a character flaw. It's what the incentive structure produces, in me and in basically anyone billing by the hour.
The 2025 Stack Overflow Developer Survey still shows a wide compensation spread among independent and freelance developers, wider than salaried roles show, and I don't think that's purely a skill gap. A meaningful chunk of it is pricing method. Two developers with comparable skill can land in very different places depending on whether one is trading hours for dollars and the other is pricing the outcome.
What I actually quote now
For anything with a defined scope, a new feature, a migration, a redesign, I quote a fixed project price, not a rate. I still track my hours privately so I can calibrate future quotes, but the client never sees an hourly number. The quote is built from three questions I ask myself before I write it: what does this project need to actually solve for the client, what's the real risk that scope grows once I'm inside the codebase, and what would I charge if I could only send one invoice for the whole thing.
That third question changes the number more than the first two combined. When I imagine sending exactly one invoice with no do-overs, I stop lowballing the parts of the project I'm least certain about, the parts where "should take a day" has a real chance of taking four.
For ongoing work, a retainer or an indefinite maintenance relationship, I do still use a day rate rather than a project price, because the scope genuinely isn't fixed and pretending otherwise would just mean padding a fixed number to cover uncertainty I can't quantify yet. Day rate, not hourly. Clients stop watching the clock and start describing what they need, which produces better conversations than a stopwatch relationship ever did.
The discovery call is where the pricing actually happens
I used to treat the discovery call as a formality before sending a quote. It's the opposite. The call is where I find the information that makes the quote accurate instead of a guess. I ask what happens if this project is late, not because I want to threaten anyone with lateness, but because the answer tells me how much risk I'm actually taking on. "Nothing happens, we'll just launch next quarter instead" is a different project than "our biggest client renews in six weeks and this has to be live before then." Same scope, same code, genuinely different price, because the second one is buying certainty as much as it's buying software.
I also ask directly who else has quoted this and what they said, not to undercut a competitor, but because a wildly different range from another freelancer usually means we're scoping different things, and finding that mismatch before I quote saves both of us from a bad first few weeks.
Scope creep is a pricing problem wearing a project management costume
Most scope creep advice focuses on process: change orders, signed amendments, tracked hours against a budget. Useful, but it treats the symptom. The actual cause, in my experience, is that the original quote never accounted for the parts of the project that were genuinely unknown at quoting time. You can't change-order your way out of a quote that was wrong from the start; you can only patch it, and patched quotes are where resentment lives on both sides.
Now I build a specific line into every proposal: a fixed number of hours reserved for "things we find once we're inside the code that weren't visible from outside it." I call it exactly that, in plain language, not a vague buffer percentage. Clients respond well to it because it's honest about the actual nature of the work instead of pretending I can see through a black box from a kickoff call.
What I do when a client pushes back on the number
I used to fold immediately, because I hate confrontation about money more than I hate most things, and my quotes at the time were often a first offer I expected to negotiate down from anyway. Two changes fixed this. First, I stopped quoting a padded first number, so there's genuinely less room to negotiate downward without cutting the project's scope along with the price. Second, I started answering pushback with a scope question instead of a price question: "what part of this would you want to cut to hit that number?" That reframes the conversation from "convince me I'm worth this" to "let's agree on what we're actually building," which is a conversation I'm far more comfortable having, and one that usually produces a smaller, cleaner project instead of an awkward discount on the original one.
The math I actually run before I type a number
When I'm building a fixed quote, I still start from a rough hours estimate, I just don't stop there. I take my target day rate, multiply by my honest estimate of days, then apply a multiplier based on how well I understand the codebase going in. A greenfield project where I'm writing every line gets close to a 1.1x multiplier, barely any padding, because the unknowns are mine to control. A project where I'm the fourth developer to touch an unfamiliar codebase gets 1.4x or higher, because the discovery call can't show me what a previous developer left half-finished three directories deep. That multiplier isn't padding in the dishonest sense. It's pricing the actual risk I'm taking on by agreeing to a fixed number against work I can't fully see yet, and naming it explicitly, even just to myself, keeps me from either underpricing real uncertainty or overcharging a client whose codebase turns out to be cleaner than I expected.
I also stopped rounding quotes to numbers that feel comfortable, the way $5,000 feels safer to type than $5,400. A specific number reads as calculated rather than guessed, and in three years of sending both kinds, the specific ones get fewer "can we talk about the price" emails, not more.
One thing to try this week
Take the last project you quoted hourly and rewrite the quote as a single fixed number, using the "one invoice, no do-overs" question above. Don't send it anywhere. Just see what the number does to how you'd approach the work, and notice which parts of the original scope you'd suddenly want nailed down before you started. That gap between the two numbers is usually where the real pricing problem was hiding.
I wrote a longer breakdown of the actual proposal document I send after a discovery call in an earlier post on the section that wins the job, if you want the template alongside the pricing logic here. More about how I run this as a business is on my about page.
Originally published at abrarqasim.com. I write there about React, PHP, Rust, Go and the AI tooling around them.
Top comments (0)