billable.devFreelance Developer Hourly Rates: What to Charge
By Mark Fulton · 2026-08-31 · 15 min read
Your rate is an output, not a guess. Start from the income you want to keep, add the overhead you actually pay, add a tax reserve, then divide by the hours you can realistically bill in a year. That division gives you a floor: the number below which the year does not work no matter how busy you are. Market data comes in after that, as a sanity check on whether your floor is sellable to the clients you want. Do it in that order and you can defend the number in a call, because you can show where every dollar of it goes. Do it the other way around, by copying an average off a chart, and you will spend the year discovering which of your costs the average forgot about.
What do freelance developers actually charge?
The honest answer is that published rate figures disagree with each other by roughly eight times, and most of them are measuring something other than what you are about to sell.
Clockify's published averages put the average hourly rate for a software developer at $33.21 and a web developer at $26.27, drawn from job boards and marketplace data. A hiring guide published by goLance reports tiers running from about $25 an hour for junior talent up to $275 an hour for top specialists, with a mid level average around $73. FullStack's 2026 price guide, citing a Techreviewer survey of 127 development providers, reports that the largest single band of vendors bills $30 to $49 an hour and that roughly nine in ten bill under $100.
Those numbers are not wrong. They are answers to different questions. Marketplace medians describe a global bidding pool where a US contractor competes on the same listing page as someone with a very different cost of living. Job board averages describe advertised roles, many of them part time or offshore. Agency vendor surveys describe shops with sales teams and account managers, priced per seat.
A more useful anchor for a US based developer going independent is what the equivalent employment pays, because that is the option you gave up. Stack Overflow's 2025 Developer Survey salary data reports a median annual total compensation in the United States of $138,000 for full stack developers, $145,000 for front end developers, and $175,000 for back end developers. Those are salaried numbers with employer paid payroll tax, subsidised health insurance, paid time off, and hardware included. Every one of those things becomes a line item you pay yourself the moment you go independent, which is exactly why a freelance rate that simply converts a salary to an hourly figure comes out too low.
So treat every published range as context, not as an instruction. The number you charge comes out of your own arithmetic.
How do you calculate your floor rate?
Five steps. Work them in order, and write down the assumption behind each one so you can revisit it later. The assumptions below are placeholders. Replace every one with your own figure.
Step 1: name the income you want to keep. For this worked example, the target is $120,000 in your pocket after tax. Be explicit about which side of tax you mean, because it changes the answer by about 40 percent. Take home is the harder and more honest target.
Step 2: gross the target up for a tax reserve. Self employment tax alone is 15.3 percent, split as 12.4 percent for Social Security and 2.9 percent for Medicare, according to the IRS guidance on self employment tax. Federal income tax and any state tax sit on top of that. This example assumes a combined reserve of 30 percent of business profit, which is a round placeholder, not a prediction about your situation. Ask your accountant for your real number and use that instead. This is general information, not tax or legal advice.
$120,000 divided by 0.70 gives $171,429 of profit you need to earn before setting the reserve aside. The reserve itself is $51,429.
Step 3: add your overhead. These are the costs of running the business, which come out before profit. A representative solo developer's year:
| Overhead line item | Annual cost |
|---|---|
| Health insurance (self paid) | $9,600 |
| Hardware, amortised (laptop, monitors, phone) | $2,400 |
| Software and services (hosting, CI, IDE, domains, design tools) | $1,800 |
| Bookkeeping and tax preparation | $1,500 |
| Business insurance (general liability, errors and omissions) | $1,000 |
| Legal (contract templates and review) | $600 |
| Learning (courses, conferences, books) | $1,500 |
| Site, portfolio and marketing | $600 |
| Total overhead | $19,000 |
Yours will differ. If a client requires errors and omissions cover at a specific limit, that line grows. If you are on a spouse's health plan, the biggest line disappears and your floor drops by roughly $8.50 an hour at the billable hours below.
Step 4: count the hours you can actually bill. This is the step most rate advice skips, and it is the one that decides the answer.
Start with 52 weeks. Take out four weeks for vacation and public holidays and one week for illness and the days that simply do not happen. That leaves 47 working weeks. Now apply a realization rate: the share of your worked hours that a client is actually charged for. The rest goes to proposals, scoping calls, invoicing, chasing payment, bookkeeping, sales, support you did not bill for, and the learning that keeps you employable.
At a 40 hour week and 60 percent realization, that is 24 billable hours a week, or 1,128 billable hours a year. Sixty percent is a reasonable starting assumption for a solo developer with a steady but not fully booked pipeline. Track your own for a quarter and replace it.
Step 5: divide.
| Step | Assumption | Figure |
|---|---|---|
| 1. Target income kept after tax | your choice | $120,000 |
| 2. Tax reserve | 30% of profit (placeholder) | $51,429 |
| Profit required before tax | $120,000 ÷ 0.70 | $171,429 |
| 3. Overhead | table above | $19,000 |
| Revenue required | profit + overhead | $190,429 |
| 4a. Working weeks | 52 weeks less 4 vacation, less 1 sick | 47 |
| 4b. Billable hours per week | 40 hours × 60% realization | 24 |
| Billable hours per year | 47 × 24 | 1,128 |
| 5. Floor rate | $190,429 ÷ 1,128 | $168.82 |
Round up and you have $170 an hour. Check it back the other way: 1,128 hours at $170 is $191,760 of revenue, less $19,000 of overhead is $172,760 of profit, less the 30 percent reserve leaves $120,932 kept. The target holds.
That is the floor for this set of assumptions, not a stretch goal, and it is why the marketplace averages above are not usable as a target. A developer billing $73 an hour against these same costs and hours bills $82,344, clears $63,344 in profit, and keeps about $44,300 after the reserve.
Two things move that number more than anything else.
Realization moves it most. Same $190,429 of required revenue, different assumptions about how much of your week is billable:
| Realization | Billable hours/week | Billable hours/year | Floor rate |
|---|---|---|---|
| 50% | 20 | 940 | $202.58 |
| 60% | 24 | 1,128 | $168.82 |
| 70% | 28 | 1,316 | $144.70 |
| 80% | 32 | 1,504 | $126.62 |
An extra billable hour a day is worth more to you than a rate rise, and it is usually easier to get. Cutting the admin tail of every project is the cheapest raise available.
Your target moves it next. At the same 1,128 billable hours:
| Target kept after tax | Revenue required | Floor rate |
|---|---|---|
| $80,000 | $133,286 | $118.16 |
| $120,000 | $190,429 | $168.82 |
| $150,000 | $233,286 | $206.81 |
One more framing check. If you read the $120,000 as a pre tax salary equivalent rather than take home, you skip step 2 and the arithmetic becomes ($120,000 + $19,000) ÷ 1,128 = $123.23 an hour. Both framings are legitimate. Just know which one you used, and never quote the pre tax version to yourself while planning your life around the take home one.
While you are working through step 2, set the reserve aside as it arrives rather than at year end. The IRS notes that individuals generally need to make quarterly estimated tax payments if they expect to owe $1,000 or more when they file, so the money has to be liquid on a schedule anyway. Again: general information, not tax advice.
What multiplies a rate: stack, seniority, time zone?
The floor is arithmetic. Everything above it is leverage. These are the factors that reliably move a developer's rate up, roughly in order of how much they move it.
Distance from the revenue line. Work that touches money moves at a different price to work that touches marketing pages. Payment flows, checkout, billing logic, subscription migrations, data pipelines that feed a pricing model: when those break, the client counts the cost per hour, so they buy on speed and confidence rather than on rate. A developer who can say "I have migrated three Stripe billing systems without a failed charge" is not competing on the same axis as one who builds landing pages.
Scarcity of the specific stack, not the popular one. Being another React developer is not leverage, because the supply is enormous. Being the person who knows a legacy framework a live business still runs on, or a niche compliance domain, or a rendering pipeline, is leverage. The premium comes from the size of the pool, not the modernity of the tool. This is why rescue work, legacy migrations, and "the previous contractor disappeared" projects price higher than greenfield.
Seniority measured in decisions, not years. Clients pay for the decisions you can make without supervision. Can you scope the work yourself, choose the architecture, say no to a bad requirement, and be right often enough? A developer who needs a written ticket for every task is buying and reselling hours. A developer who can be handed an outcome is selling judgment, which has no obvious ceiling.
Time zone and availability overlap. Overlapping business hours with your client is worth real money, because it removes a day of latency from every question. The same is true of genuine responsiveness during an incident. If you are far from the client's clock, you can sell asynchronous discipline instead: crisp written updates, no blocking questions, work that lands overnight. Both are sellable. Neither is free to provide, so price it.
Who is buying. Agency subcontract work pays less than direct client work, because the agency is carrying the sales cost and the client relationship, and it takes its margin from your rate. That is a fair trade when it means predictable volume and no selling. Just do not confuse a subcontract rate with your market rate. A funded startup replacing a missing hire, an established business with a revenue-critical system, and an agency filling a gap are three different buyers with three different budgets for the same code.
Engagement shape and risk. Short, urgent, high-consequence engagements price above long, steady ones. A retainer or a long block trades rate for predictability, and that trade is often worth making: a slightly lower rate on 20 guaranteed hours a week beats a higher rate on an empty calendar, because the calendar is the thing your floor calculation is most sensitive to.
Note what is missing from that list: how long you have been freelancing, how hard the work felt, and what you charged your last client. None of those is an input the buyer cares about.
When should hourly give way to fixed pricing?
Hourly billing is the right instrument when the scope is genuinely unknown, when you are being bought as capacity rather than for an outcome, or when the client controls the pace of the work. Discovery, ongoing maintenance, incident response, and "sit with our team for a few weeks" engagements all fit that shape.
It becomes the wrong instrument in three situations.
The first is when you get faster. Hourly billing punishes exactly the thing you are spending your evenings improving: an engineer who ships in six hours what took twelve last year earns half as much for the same result. The fix is not to pad hours. The fix is to price the result.
The second is when the client is buying a defined deliverable with a defined edge. A marketing site, a Shopify integration, an audit, a migration with a clear before and after: these have a scope you can write down and a value the client can name. Fixed pricing lets you keep the upside of your own efficiency and gives the client the budget certainty they were probably asking for when they asked your rate.
The third is when the hourly number has become the whole conversation. If a client is negotiating $150 down to $135, you are being compared on a unit that has nothing to do with their outcome. Repackaging the same work as a fixed price with a stated deliverable moves the conversation back to what they get.
Your floor rate still governs the fixed price. Estimate the hours honestly, multiply by the floor, add a contingency for the parts you have not seen, and that is your minimum. The fuller comparison, including which one clients actually prefer and how to move a client from one to the other mid relationship, is in hourly vs fixed price billing for developers.
Whichever you choose, the rate only becomes income when the money arrives, so pair it with terms that protect the schedule your floor assumed: a deposit before work starts, short net terms, and a late fee you actually apply. That side of the equation is covered in getting paid on time with net terms, deposits and late fees.
How do you state the rate on invoices and proposals?
State it once, plainly, and in the same form everywhere it appears. Rate confusion is one of the most common causes of a delayed payment, and it is entirely self inflicted.
In the proposal, put the rate next to what it buys, and name the unit and the currency without ambiguity: "$170 per hour, USD, billed in 15 minute increments, invoiced every two weeks, net 14". If there are conditions, write them there rather than discovering them later: a minimum engagement, a different rate for out of hours or weekend incident work, a travel policy, a cap after which you check in before continuing.
In the contract, the rate belongs with the change control clause. A rate is only as solid as the scope it attaches to, and the sentence that saves you is the one that says what happens when the scope moves.
On the invoice, show the rate on every line item, not just as a total. A line that reads "Development work, $6,800" invites a question. A line that reads "API integration and error handling, 12.5 hrs at $170/hr, $2,125" answers it before it is asked. Group by deliverable rather than by day, so the client reads outcomes and sees the hours as supporting detail. The full field by field breakdown is in what belongs on a software development invoice, and the end to end process, including numbering and payment details, is in how to invoice as a freelance developer.
If you already track your work in commits, you can build those line items from the record instead of from memory. Turning your git log into an invoice walks through grouping commits into billable deliverables, which is also the fastest way to stop losing the half hours that quietly drag your realization rate down.
Set your default rate once in billable.dev and every line item you add uses it, so the number in your proposal and the number on your invoice cannot drift apart. It runs entirely in your browser, with no account and no server, and you can start from the free invoice template for developers if you would rather see the finished shape first. Pro is $4 a month billed at $24 for six months, or $79 once for lifetime, if you want saved clients and recurring invoices later.
Frequently asked questions
Is $100/hr too much for a mid-level dev?
Run the arithmetic before answering that. At the assumptions in the worked example above, $19,000 of overhead, 1,128 billable hours, and a 30 percent tax reserve, $100 an hour produces $112,800 of revenue, roughly $93,800 of profit after overhead, and about $65,700 kept once the reserve is set aside. Whether that is too much depends entirely on whether it covers the life you are funding, and on the buyer. It is well above the marketplace averages published by Clockify and near the top of the mid level band in goLance's hiring guide, so it will feel high to a client shopping on a bidding platform. It will not raise an eyebrow at a funded startup replacing a departed engineer. Pick the buyer first, then the rate.
Should my rate differ by client size?
Your floor should not. What sits above it can, and usually does, because larger clients genuinely cost more to serve: procurement, security questionnaires, insurance requirements, more stakeholders in every decision, slower payment cycles that you are financing. Charging a larger organisation more for the same code is not opportunism if you are also absorbing more overhead and more risk to work with them. What does not work is quoting different rates to comparable clients and hoping they never talk. Keep one published rate, and vary the shape of the engagement (minimums, retainers, prepaid blocks, discounts for volume or for long commitments) rather than inventing a different number each time.
Do I show my hourly rate on the invoice?
Yes, on hourly work. Rate times quantity on each line item is what makes an invoice self explanatory, and it is what an accounts payable clerk needs in order to approve it without asking you a question that costs a week. The exception is fixed price work, where the invoice should show the deliverable and the agreed amount, not a reconstructed hourly breakdown. Showing hours on a fixed price invoice reopens a negotiation you already closed, and it teaches the client to evaluate your efficiency instead of your result.
How often should rates go up?
Once a year is a workable default, applied to new engagements and to existing clients with notice. Two triggers should override the calendar. The first is demand: if you have turned down work or been booked solid for a quarter, your rate is under market and the market is telling you so. The second is your own arithmetic: rerun the floor calculation whenever a real input changes, which usually means a health insurance renewal, a move, a change in what you want to earn, or a measured shift in your realization rate. Give existing clients notice in writing, name the new rate and the date it starts, and do not apologise for it in the message. Most clients accept a rise from someone who is already doing good work, because replacing you costs far more than the difference.