How to price contract software engineering

Contract engineering gets benchmarked against a salary that doesn't include your risk, your gaps, or your costs. Here's how to price a contract rate that actually beats employment.

What you're actually selling

Senior capability with no notice period, no recruitment fee, no onboarding ramp, and no severance. The client is buying speed and optionality, and both are worth a premium over a permanent hire.

Why software engineers get this wrong

Clients — and plenty of engineers — convert a salary to a day rate by dividing by 260. That maths ignores every gap between contracts, every unbilled day, employer pension and national insurance, your own equipment and training, and the fact that a contract can end with a week's notice. A rate that merely matches a salary is a pay cut with extra risk.

How to work out your number

  1. Start from total employment cost, not gross salary

    The equivalent permanent hire costs the business considerably more than their salary once employer contributions, benefits, equipment, and recruitment fees are counted. That total is the honest comparison point for your rate.

  2. Price in the days you won't bill

    Contracts end, notice periods bite, and there are always weeks between engagements. Assume a realistic number of billable days in a year rather than a full calendar, and let the rate carry the gaps.

  3. Charge for the risk you're carrying

    No sick pay, no holiday pay, no redundancy, and termination on short notice. Every one of those is a cost the client has moved onto you, and the rate is the only place it can be recovered.

  4. Decide what you'll do beyond the code

    Architecture decisions, mentoring, on-call, and hiring input are senior work that quietly gets absorbed into a delivery contract. Either scope them in and price them, or scope them out.

Pricing models that fit software engineers

Think twice about: Performance-based pricing

Engineering outcomes depend on product decisions, priorities, and teams you don't control. Tying your fee to metrics you can't move is a bad trade.

Mistakes that cost you money

  • Converting a salary to a day rate by dividing by 260 and pricing in none of the risk.
  • Assuming you'll bill every working day of the year.
  • Letting a delivery contract quietly expand into architecture ownership and on-call.
  • Signing extended notice terms in one direction only — theirs short, yours long.

Ask these before you quote

  • How long is the initial contract, and what's the notice period on each side?
  • Is this delivery work, or am I owning architecture and technical decisions?
  • Is there an on-call or out-of-hours expectation?
  • Who else is on the team, and what's blocking them right now?

Software Engineers: frequently asked questions

How do I convert a salary into a contract day rate?

#

Don't divide by 260. Start from the total cost of an equivalent permanent hire, divide by the days you'll realistically bill in a year rather than every working day, then add a premium for the sick pay, holiday, pension, and job security you've given up.

Should a contract rate be higher than a salary?

#

Substantially, yes. You're covering unbilled gaps between contracts, your own equipment and training, employer-side contributions, and termination risk on short notice. A rate that merely matches the salary leaves you worse off than the permanent role.

Is a day rate or a fixed fee better for engineering contracts?

#

Day rate for open-ended or team-embedded work, where priorities shift and you don't control the scope. Fixed or milestone fees for clearly defined deliverables you've built something similar to before.

How do I raise my rate on a contract extension?

#

Raise it at renewal, not mid-term, and give notice well before the current contract ends. Extensions are the strongest position you'll ever negotiate from: they know your value, and replacing you costs them ramp-up time they've already paid for once.

Get the deep dives

Worked examples and scripts for every pricing model. No spam.