You have two quotes on your desk. One says a single number. The other says an hourly rate and an estimate. Both look reasonable, and you are not sure which one is safer.
Here is our position. For most small businesses in Raleigh and the Triangle, fixed price is the better default. But it is not always the right call, and a bad fixed price is worse than a good hourly deal.
What is the difference between fixed-price and hourly web design?
With fixed price, you and the studio agree on what gets built and what it costs. The number holds as long as the scope holds.
With hourly, you pay for time spent. The studio tracks hours, bills them, and usually gives you an estimate or a cap to plan around.
That is the whole mechanical difference. The real difference is who carries the risk when the project turns out harder than expected.
Who does each billing model protect?
Fixed price protects you. If a page takes longer than planned, that is the studio's problem. You can budget with confidence and say yes to the project without wondering what the final invoice will be.
Hourly protects the studio. Every hour of work gets paid, including the hours spent on a surprise integration or a fourth round of revisions.
Neither is dishonest. They simply put the uncertainty in different places:
- Fixed price: the studio absorbs uncertainty, so a good one asks more questions up front.
- Hourly: you absorb uncertainty, so you need to watch the project more closely.
If you run a business and do not have time to audit a timesheet, that matters.
Where do surprise costs come from in an hourly project?
Rarely from bad intent. Usually from drift.
Someone asks, "Can we also add a booking form?" Someone else wants the homepage reworked after seeing it in a browser. A decision waits two weeks, and the team has to reload context when it returns. None of these feel like big decisions. Each one adds hours.
Common sources of hourly overruns:
- Feedback that arrives piecemeal instead of in one round
- Content that is late, so design gets redone around the real words
- New features added mid-build
- Approvals that reverse earlier approvals
- Third-party tools that behave differently than the documentation promised
Under hourly billing, nothing pushes back on any of this. The meter just runs. That is why an estimate is not a cap, and why you should ask which one you are getting.
Where does a fixed price go wrong?
A fixed price fails in two ways.
First, the scope is vague. If the proposal says "a custom website" and little else, the studio and you each imagine something different. The argument arrives at the end, when everyone is tired.
Second, the price is padded. A studio that fears the unknown may add a cushion to cover it. You pay for risk that never happened.
There is a third, quieter problem. When a fixed price is too low, the studio has every incentive to cut corners to protect its margin. You get the site you paid for, built a bit thinner than you hoped.
The fix for all three is the same: a scope written in plain language.
How does a clear scope make either model work?
A clear scope turns a vague project into a checklist. It is the difference between a quote you can trust and one you can only hope about.
A useful scope names:
- The pages and templates being built
- The features, such as forms, booking, a store, or a blog
- What content you provide and when it is due
- How many rounds of revisions are included
- What happens to anything not on the list
Notice that this is about what the site does, not how many hours it takes. Cost follows scope and features. A ten-page brochure site and a site with online scheduling and account logins are different projects, even if two people could theoretically bill the same hours for each.
With a clear scope, hourly stays predictable and fixed price stays fair. Without one, both go sideways.
What questions should you ask before signing?
Bring these to every proposal, whichever model it uses:
- What exactly is included? Ask to see it in writing, page by page and feature by feature.
- What counts as a change? A new page is clearly out of scope. A different button color probably is not. Find the line now.
- How are changes priced? A change request should come with a cost before the work begins, not after.
- How many revision rounds are included? And what happens at the end of them?
- What do you need from us, and by when? Late content is the most common reason projects slip.
- Who owns the site at the end? You should own your domain, your content, and your code.
A studio that answers these cleanly is a studio that has run projects before. If the answers are fuzzy, the invoice will be too.
How do ongoing changes and maintenance get billed?
This is where small businesses get caught, because the launch quote feels like the whole story. It is not.
Sites need updates. A hours-of-operation change, a new service page, a plugin that needs patching, a form that stops sending email. Ask before you sign how this work is handled.
Common arrangements include a monthly maintenance plan, a block of prepaid hours, or simple hourly billing for small requests. Any of them can be fair. What matters is that you know which one you are getting.
Note that hourly billing often makes more sense after launch than before it. Small, unpredictable tasks are hard to price as a fixed fee, and an hourly rate for them is honest.
Which model suits which kind of small business?
Choose fixed price if:
- You can describe the site you need, even roughly
- You have a budget ceiling you cannot cross
- You are a service business, a local shop, or a practice with a clear set of pages
- You do not have time to monitor a project week to week
Choose hourly if:
- You are still figuring out what the product or service is
- The project is exploratory, like testing an idea or untangling a messy existing site
- You want to stay closely involved and adjust as you go
- The work is a series of small fixes rather than a single build
Many projects land in between. A fixed price for the defined build, then hourly or a plan for what comes after, is a combination we think works well for most.
If you want to see what a fixed-scope build looks like, our custom web development page lays out how we approach it.
Your next step
Before you request any quote, write down the pages you think you need and the three things the site must do. One page is enough. Then tell us about your project and compare what comes back. The proposal that repeats your list most clearly, with a price attached, is usually the one to trust.