Pricing is where I lost the most money early on. I knew how to build the work, but I did not yet know how to price the uncertainty around the work, which is where freelance web projects actually get expensive.
I started with hourly because it felt safe
Hourly pricing is easy to explain, especially when you are new. You tell yourself it is honest, transparent, and flexible. The client pays for the time, you log the time, nobody gets surprised.
That is not how it usually plays out on web projects.
My early numbers looked like this:
- Small brochure site: 25 hours at $60 per hour = $1,500
- CMS refresh with content migration: 40 hours at $65 per hour = $2,600
- Landing page plus email capture integration: 15 hours at $60 per hour = $900
The estimates looked reasonable. The problem was that I was only pricing the visible work. I was not pricing the client delay, the revision drift, the “can we just see one more option” round, the time spent cleaning up copy in Google Docs, or the half-day I would lose untangling hosting access.
One project finally made the problem too obvious to ignore. It was a five-page marketing site for a local services business. I estimated 28 hours at $60 per hour, so the quote landed at $1,680. The actual project took 47 hours once the feedback loops, rewritten page copy, and redesign of the homepage hero were included. My effective rate dropped to about $36 per hour before software costs, taxes, and admin time.
Hourly pricing also created the wrong emotional dynamic. Every time I improved my process, the client paid less because I got faster. Every time the project got messy because the client was slow or indecisive, I had to either bill more and start a fight or quietly absorb the difference.
Web clients are rarely buying hours. They are buying a finished outcome, and the more you price the work like a timesheet, the more you invite the wrong conversation.
Project pricing fixed the obvious leak
The next move was simple fixed pricing. Instead of estimating hours and multiplying them by a rate, I started pricing by project type and complexity.
That looked more like this:
- Basic brochure site with up to six pages and one revision round: $3,800 to $4,800
- Marketing site with CMS, templates, and light SEO setup: $6,500 to $8,500
- Larger redesign with messaging workshop, copy guidance, and launch support: $9,000 to $14,000
I still used time internally, but only as a private planning tool. The client saw a clear project fee, a payment schedule, and a scope definition tied to deliverables instead of effort.
First, it gave me room to price the invisible work. I could finally account for discovery, project management, revisions, launch coordination, and the general cost of being the person holding the whole thing together.
Second, it made the proposal easier to understand. A client looking at a fee of $7,200 for a website redesign can compare that against their budget and their goals. A client looking at 96 hours at $75 per hour tends to zoom in on the hours and start negotiating the wrong part of the equation.
Third, it forced me to get much better at scoping. That mattered more than the pricing model itself. Once I had to put a real project fee in front of someone, I finally got serious about defining what was included, what counted as a revision, and what happened when the work changed. If your pricing keeps drifting, go read what to put in your freelance web contract next, because pricing and contract language are attached at the hip.
Project pricing did not make me magically good at estimating. It just made the estimation problem impossible to ignore. I still underquoted some work, usually by 15 to 25 percent, especially when I was too eager to win the project. But at least the leak was visible.
Value-based pricing only works when you understand the client’s stakes
“Charge for value, not time.” That advice is directionally right, but incomplete enough to get people in trouble.
If you hear “value-based pricing” and interpret it as “add a zero because the client is a business,” you will end up with flimsy proposals and a lot of awkward calls.
What changed my pricing was learning to ask better questions before I quoted:
- What is the site supposed to do that it is not doing now?
- What happens if this project gets delayed three months?
- Who approves content and design decisions?
- Is this replacing a site that is already generating leads or sales?
- What does success look like in six months?
When I started asking those questions, some projects stopped looking like $5,000 brochure builds and started looking like high-stakes operational work.
One example: a small B2B firm came in wanting “a cleaner site with better messaging.” On the surface, that sounded like a normal seven-page redesign. But once we got into the call, the real issue was that their current site was attracting almost no qualified leads, the founder was handling every inquiry manually, and the sales team had no consistent way to route prospects. That is a website, messaging, form flow, and content structure problem with revenue consequences.
I still checked my internal production math. But instead of pricing it like a page-count exercise, I priced it as a business-critical marketing rebuild. The proposal landed at $11,500 with discovery, messaging alignment, content structure, build, launch, and a post-launch review window. The same project would have been maybe $6,500 in my earlier pricing model.
Value-based pricing, in practice, is not mysterious. It is just pricing the importance and risk of the work instead of pretending all websites are the same shape.
The pricing math I use now
I use four layers.
1. Start with a private production floor
I estimate the real working time, multiply it by the rate I need the project to clear, and then add contingency.
A rough example:
- Discovery and planning: 8 hours
- Design direction and revisions: 14 hours
- Build and QA: 22 hours
- Launch, training, and wrap-up: 6 hours
- Project management and communication: 8 hours
That puts the core workload at 58 hours. If I need the project to clear about $115 per working hour to make sense in my business, the internal floor is $6,670. Then I add 15 to 20 percent for uncertainty. Now the proposal wants to be somewhere in the $7,700 to $8,000 range before I even think about value.
2. Price the decision load, not just the production
If I can see that the client is organized, has one decision-maker, and already has strong copy, I stay closer to the floor. If I can see multiple stakeholders, vague ownership, slow internal approvals, or a lot of “we’re still figuring that out,” I move up.
That is not padding. That is pricing risk honestly.
3. Adjust for business importance
If the site is lightly important, like a modest refresh for an existing referral-based business, I usually keep the proposal conservative. If the site is a central sales tool, a launch asset, or the public face of a serious rebrand, the fee should reflect that.
4. Tie payments to milestones
I almost never do fifty tiny invoice events anymore. I keep it simple:
- 50 percent to book the project
- 25 percent at the approved design or build midpoint
- 25 percent before launch or handoff
I send invoices through Stripe Invoicing or a proposal and invoicing tool such as Bonsai, because payment friction is still friction. If you want the onboarding side of this, the client onboarding checklist I use for every project covers the handoff from signed agreement to kickoff.
What I got wrong for years
The biggest mistakes were embarrassingly ordinary.
I priced based on what felt fair to the client instead of what the project would actually cost me to run.
I priced visible deliverables but ignored coordination, revision load, and the cost of context switching. That kind of invisible overwork is also how burnout builds — the same pattern, seen from the energy side instead of the financial side.
I treated scope as a loose conversation instead of a financial boundary.
And I was too afraid to say, “that request changes the fee.” If that part sounds familiar, how to say no to a client without burning the relationship is the companion piece, because pricing only works when you are willing to hold it.
Pricing got easier when I stopped looking for the perfect formula and started building a repeatable one. You do not need a pricing framework from someone who has never sent an invoice. You need a floor, a scope, a contingency allowance, and enough nerve to charge for the project that is actually in front of you.
What I’d actually do
If your pricing still feels slippery, stop trying to become a genius estimator overnight. Pick one project type you already do often, write down the real hours it usually takes, add a contingency buffer, and turn that into a clear fixed-fee offer with milestone billing. Then tighten the scope language around it. That one change will teach you more than another month of reading pricing threads.