How to price development work

Estimates are wrong, scope moves, and the last 10% takes 40% of the time. Here's how to price client development work so that reality doesn't come out of your margin.

What you're actually selling

A working thing the client's business depends on, plus the confidence that it won't fall over. The code is the artefact; the reliability is the product.

Why developers get this wrong

Developers quote the happy path. The estimate covers building the feature, not the third-party API that's undocumented, the legacy data that's malformed, the client who takes eleven days to give feedback, or the last mile of testing and deployment. Then the fixed fee is fixed and the overrun is yours.

How to work out your number

  1. Never fix a price on a scope you haven't seen

    If the requirements are vague or the existing codebase is unknown, sell a paid discovery phase first. You come out of it with a scope you can price properly, and the client comes out with a document that's worth having either way.

  2. Estimate the work, then estimate the friction

    Integrations, data migration, review cycles, environments, QA, and deployment routinely add more than the feature work itself. If your estimate doesn't have a line for them, it isn't an estimate, it's a hope.

  3. Break the project into billable milestones

    Split delivery into stages with a payment attached to each. It caps your exposure if the project stalls, keeps cash moving, and gives both sides a natural checkpoint to re-scope rather than argue.

  4. Price the tail separately

    Bug fixes, hosting, dependency updates, and 'can you just change this' are not part of a build fee. Quote them as a support retainer from the start, before the client assumes they're free.

Pricing models that fit developers

Think twice about: Hourly rate

It makes you slower for money, invites line-by-line scrutiny of your commits, and caps your income at the hours you can physically work.

Mistakes that cost you money

  • Fixing a price on a brief that's still a conversation rather than a document.
  • Estimating the code and forgetting testing, deployment, review cycles, and integrations.
  • Absorbing 'small' change requests instead of quoting them, until they add up to a month.
  • Handing over the build with no support agreement, then doing unpaid fixes forever.

Ask these before you quote

  • Is there an existing codebase, and can I see it before I quote?
  • Which third-party systems does this have to talk to, and are they documented?
  • Who tests and signs off each stage, and how quickly?
  • What happens after launch — who maintains it?

Developers: frequently asked questions

Should developers charge hourly or a fixed price?

#

Fixed or milestone-based when the scope is genuinely defined and you've built something comparable before. Hourly when the work is exploratory, the codebase is unknown, or the client can't yet say what they want. The deciding factor is who can reasonably carry the uncertainty.

How do I estimate a development project accurately?

#

Break it into the smallest pieces you can price, add explicit lines for testing, deployment, integrations, and review cycles, then check the total against a similar project you've actually delivered. If you have no comparable project, sell a paid discovery phase instead of guessing.

How do I handle scope creep as a developer?

#

Write the scope down, then treat everything outside it as a change request with its own price and timeline, sent in writing before you start it. Most creep comes from a scope that was never specific enough to point at.

Should I charge for maintenance after a project ships?

#

Yes, and agree it before launch. A monthly support retainer covering fixes, updates, and a set number of change hours is standard, and it turns a one-off build into recurring income.

Get the deep dives

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