Before you say a number, get the client to say one first. Not your cost. Theirs. Ask what the problem is already costing the business, and let that figure sit on the table, in their own words, before you talk about fees at all. Everything below unpacks that one move: why hourly billing quietly punishes you for getting good at the job, the three numbers that replace it, how to size value when nobody will hand you a salary figure, and how to package the result so the client argues about which option to pick, not whether to hire you at all.
Say their number before you say yours
Here's the one rule worth leaving with: before you say any price, get the client to tell you what the problem is costing them. Walk them through the diagnosis first: how the system would work, what testing looks like, how it changes their speed or their error rate. Only then get into money. Some clients want a number immediately. The honest answer is that an accurate estimate needs a real look at the complexity of the system and how it fits their actual process, not a guess made in the first five minutes.
Once a credible number is on the table, in the client's language, your price is just a fraction of it. You're not selling hours of build time. You're selling the result, and the build is simply how that result gets delivered.
Why hourly pricing punishes getting good
The obvious question is why not just bill hourly and be done with it. The problem is that hourly pricing pays you to be slow.
Picture two developers on the same team, both billed at $150 an hour. The strongest one finishes a feature in a day, so that's a day billed. The slower one takes three days for the same feature, so that's three days billed. The weaker performer just made three times the money. And if the fast developer gets even faster, the provider earns less for the same result. The incentive runs backwards: get better at the job, and your income drops.
Now put that in 2026. Once you're fluent with the current generation of coding assistants, an afternoon's work can replace what used to take a week. Under hourly pricing, that afternoon just cut your income, because you moved fast instead of slow.
None of this makes hourly billing forbidden. For your first two or three engagements, when you have no case studies and nothing to point at yet, hourly is a safer, easier ask for the business owner, and a reasonable place to start. Something like $100 an hour is a fine opening number. Just plan to stop billing that way once you have proof.
Three numbers: cost, value, and the price between them
If you're not pricing off hours, you're pricing off three numbers instead: cost, value, and price.
Cost is your floor: the number below which you'd walk away. Value is the client's ceiling: the most this is worth to their business. Price is whatever you both land on between those two. On an AI build, that gap is usually wide, because what it costs you to build and harden the thing has very little to do with what the client no longer has to spend, lose, or hire for.
Keep this line in your head: cost doesn't justify price. Price justifies cost.
Think about a landscaper who's mowed the same lawn every week for $100. One week he shows up, does the exact same job on the exact same lawn, and tells you it's $200 now because he bought a new truck and his costs went up. Nobody accepts that. His rising costs aren't your problem, and they aren't value you received. The same logic runs through your own invoice: your costs going up doesn't obligate the client to pay more, and your costs being low doesn't obligate you to charge less. The client's ceiling, what the outcome is worth to them, is the number you're actually pricing against.
Discovery comes before the number
You get one conversation to find that ceiling, and it happens before you quote anything. As you're learning about the business, you're uncovering scope at the same time as you're uncovering value, so let the client talk first: what they've tried, what's worked, where it keeps getting stuck. Your job is to listen, repeat what you heard back in plain language, and poke: ask a specific enough question that it surfaces frequency, cost, or consequence. Then pivot to what changes after the project is done, and what the best-case outcome actually looks like for the business.
From there, run three questions. Why this: does what they're asking for actually produce the outcome they want, or did they walk in asking for an agent when the real fix is a simple script and a notification? Why now: is there a closing window or competitive pressure that makes this urgent, because urgency is real money to you. Why me is the uncomfortable one: ask directly why they wouldn't just build this internally, or hand it to an intern. When someone says, honestly, that yes, an intern probably could get a version running, don't argue with it. Ask instead who's going to be watching it at 2 a.m. when a model updates, and who scales it once throughput is far beyond what they expected. Then stop talking and let them answer. Their answer is the real reason they're looking for outside help, and you'd rather hear that objection now than read it into their silence after the proposal lands.
If they keep pushing for a number before you've had the chance to ask any of this, don't blurt one out. Say plainly that an accurate estimate needs a bit more understanding of the complexity first. And if all they want is a quote to line up against two or three other vendors, take that seriously: some buyers are shopping for the cheapest labor, not a partner, and there's not much you can do about it except recognize it early and not take it personally.
Sizing the value when the client won't hand you a number
Most clients won't just tell you a salary or a bottom-line figure, and they don't have to. Start with three sizing questions instead: how long does this take today, how many people touch it, and what happens when it goes wrong. None of these ask about the build. They measure the ceiling. Then keep stacking proxy questions on top: how many locations, how many of these come in on the busiest day, that kind of thing.
If you're working through a marketplace where you have to name a number before you ever get on a call, you can still run a version of this. The job post usually tells you something about volume or headcount. Size off that, and say your assumption out loud in the quote itself, something like: "I've priced this assuming about 200 of these a month. If that's off, a 15-minute call lets us adjust the price and rework the scope." That turns a cold number into a reason for them to talk to you.
One more check matters here: if you can't land on a number, if you don't feel like you understand the value well enough to defend it, that's the signal you're not ready to write the proposal yet. Go back and ask more questions.
Turning value into a defensible price
Once you have a credible first-year value number, pick somewhere between 10% and 20% of it as your starting point. Then run the sanity check underneath it: can the client reasonably see ten dollars of value for every dollar they invest? Call it the 10:1 rule. That ratio is what makes the number hard to argue with, though it's a guide, not a promise you get to make.
Work an example the whole way through, the way you'd need to be able to on a call. A business has employees manually setting appointments: about 20 leads a week, an hour of a person's time per lead, and that person's fully loaded cost is about $40 an hour. Twenty hours a week at $40 is $800 a week; multiplied across 52 weeks, that's $41,600 a year. Price the build at 13% of that annual figure, and you land at $5,500, a return of roughly 7.6:1 in the first year alone.
That falls short of the full 10:1 target, and it's worth being honest about why: the rest of the gap is a projection, not a guarantee. As the business recovers time and the process gets smoother, the baseline of 20 leads a week tends to climb: 21, then 23, then 27, and that's where the remaining return would come from. It's a flywheel worth describing to the client, but describe it as exactly what it is, a reasonable expectation, never a number you promise to hit. Be careful never to tie your fee to a guaranteed revenue outcome you don't control.
Two lenses: hours saved vs. income protected
There are two ways to look at any automation's value, and it's worth running both. The time lens asks how many hours this frees up. It's the easiest number to find, which is why most people start there, the way the appointment-setting case above did. But it's not the only lens, and sometimes it badly understates the opportunity.
The income lens asks what this actually does to the bottom line. One of the simplest automations worth studying took a construction crew's daily phone orders and converted them into the text format the crew already used. It only saved about 45 minutes a day, a modest number under the time lens. But it also helped the business avoid roughly $12,000 a month in scheduling errors. That second figure isn't freed-up hours. It's hard dollars the business was losing every month to human inconsistency, which is why 45 minutes a day was worth so much more than it looked.
Go back to the appointment-setting example, too: it was priced purely on the labor hours it freed up. Run it through the income lens instead, and the question becomes what a converted appointment is actually worth: if each closed deal is worth several thousand dollars to the business, the system's real ceiling sits far higher than $41,600. Start with the time lens because it's concrete and easy to defend. As you get more comfortable, add the income lens on top, because it's usually where the bigger number is hiding. Surfacing it is your job, since the business owner rarely connects those dots alone.
Packaging, milestones, and the line that protects your margin
When you write the proposal, don't send one number: send three options, something like a starter tier, a growth tier, and a scale tier. One price makes the client's decision "should we hire this person." Three options make it "how should we work together," a different and easier conversation. The bottom tier has to be genuinely useful, not deliberately thin. The middle tier is usually the one built to win. Before any of the three options, the proposal opens with a few short paragraphs about where the business stands right now, in its own words and its own numbers, not about you or your pricing.
As a rough illustration: if the credible first-year value is $100,000, a three-tier structure might land around $10,000 for the entry option, $25,000 for the middle, and $50,000 for the top, with each step up backed by more scope and more value, not just a bigger number for its own sake.
Tie payment to milestones roughly 30 days apart, so you're never carrying much more than a month of unpaid work. On a $9,000 project with two milestones, that's naturally three payments: one to start, one at the midpoint, one at delivery. The catch is that each milestone has to be objective enough that it can't be argued with. "There's a proof-of-concept in the owner's hands, and when they send it a question, the agent pulls from the database and responds within a minute" is testable and provable. "The inbox agent is working as expected" is not. That's the kind of line you and the client can go back and forth on for weeks while nobody gets paid.
When a client starts asking for things that weren't on the original list, treat it as a good sign, not an annoyance: it usually means they're excited and already picturing more work with you. Don't shut it down; redirect it: "Great idea, I can see how that adds value. Let's put it on the backlog for version two," and keep the current milestones moving. If they push back on price instead, don't teach them that your number moves every time they frown. Reduce scope, not price: "It sounds like $20,000 isn't in the budget right now. Let's shrink this to a smaller piece, get it working, and build from there once it's already earning its keep."
Two boundaries protect your margin long after the contract is signed. First, keep production API and token costs on the client's account and their card: your fee covers design, consulting, building, and testing, and ongoing usage is a utility bill that belongs to whoever's using the utility. Give them an estimated monthly run cost with the volume assumption stated right next to it, clearly labeled as an estimate rather than a promise. You cover testing costs before production, usually a few hundred dollars, sometimes as much as $1,000 to $3,000 depending on how rigorous the evaluation needs to be, and fold that into the build price. Credentials switch to the client's billing once the system goes live. Second, keep maintenance separate from new functionality. A maintenance retainer, commonly around $400 a month, keeps the agreed system doing the agreed job: it covers something breaking, an API changing, a model update, an edge case that needs a tweak. It is not a subscription to new features. New functionality is a different conversation, priced separately, every time.
Whatever else changes, don't skip measuring what happened. Capture the baseline before launch: the current hours, the current error rate, whatever number you built the price around. Then check back in at 30, 60, and 90 days and show the client those numbers actually moving. Skip that step, and the improvement goes unnoticed by the person who most needs to see it, because most business owners won't connect their own gains back to your system without being shown. The gap shows up later, in the next negotiation, when you turn up with no after-state to point to and the whole pricing conversation starts from zero again. So put the baseline number in the proposal before the system goes live, and put the 30-day review on the calendar before you send it.