Developer pricing: hourly rate, fixed price or retainer?

The hard part of pricing software development isn’t the amount — it’s that you’re selling something that hasn’t finished being designed when you price it. The client asks for “an app for orders”, you give a number, and three weeks later the “one app” has acquired user roles, printouts and a link to their accounting system.

The three pricing models aren’t a matter of taste: each one puts the risk of the unknown in a different place.

The three models

• Hourly rate (time & materials): you bill the hours you worked. The risk of the unknown sits with the client.
• Fixed price: you agree an amount for a defined scope. The risk is yours.
• Retainer / maintenance contract: a fixed monthly fee for availability, updates and an agreed number of hours. The risk is shared.

When an hourly rate fits

When the scope can’t be pinned down: extending an existing system, digging into someone else’s code, migrating data from a database nobody ever documented. There, a fixed price is just a bet against yourself.

The condition for it to work: the client has to see where the hours go. An invoice for “84 hours in July” with no breakdown sparks the same conversation every month. An invoice listing the tasks and their hours sparks none.

When a fixed price fits

When you’ve done something similar before and know where the hours hide: a brochure website, an online shop on a familiar platform, an integration you’ve already built twice. Three rules keep it healthy:

1. The package describes deliverables, not intentions: “up to 5 pages”, “one contact form”, “two rounds of revisions”.
2. What’s out of scope is written down. That’s the line that will save you, not the list of what’s included.
3. Every change in scope becomes a separate quote, however small. The second “small addition” is always the start of the third.

And a 20–30% buffer on top of your estimate. That isn’t sharp practice — it’s the statistics of the profession.

The retainer: income that doesn’t depend on new projects

Every delivered project leaves behind something that needs looking after: security updates, domain and hosting renewals, backups, small tweaks. Most developers do it for free because “it’s five minutes” — and end up working a month a year for nothing.

A maintenance contract turns that into predictable income. A setup that works: a fixed fee covering updates, monitoring and up to X hours of small changes a month; anything beyond that billed at the hourly rate; response time written into the contract.

How to work out your hourly rate

Your hourly rate isn’t the salary you want divided by 160. Only about half the hours in your week are billable — the rest go on proposals, communication, admin and learning.

1. The net annual income you’re aiming for.
2. Plus social security contributions, tax, accountant, equipment, subscriptions, holidays and sick days.
3. Divided by the year’s genuinely billable hours — not your working hours.

Example: 1,100 billable hours a year (about 22 a week) and total needs of €55,000 give an hourly rate of €50. If you priced on the basis of 1,800 working hours, you’d get €30 — and you’d be working at a loss without realising it.

Remember that your prices are before VAT and that invoices may have to be reported to the tax authority (in Greece, through myDATA): the price you quote the client and the price you invoice need to be the same conversation.

What the proposal must say

1. What will be delivered, in a form that can be checked (“works on mobile”, not “modern design”).
2. What’s expressly excluded: copy, photos, translations, user training.
3. A timeline with its own dependencies: when you need content and access from the client.
4. Payment in instalments tied to milestones, with a deposit at the start.
5. Who owns the code and what happens to third-party accounts (hosting, domain, payment services).
6. What applies after delivery: a bug-fix period and maintenance terms.

Without logged hours, no price can be verified

All three models rest on the same thing: knowing how many hours each project actually took. Without that, the hourly rate is billed from memory, the fixed price is never corrected upwards and the retainer eats hours nobody counted.

In CodePro time is logged against the task and its project, an approved proposal becomes a project with its tasks, and each client’s unpaid balance updates itself. That way your next proposal is written with data, not gut feeling.

What to track every month

• Billable hours versus total hours — the percentage that tells the whole truth.
• Estimated versus actual hours per project; the difference is your next proposal.
• Open balances per client, sorted by age.
• Revenue from maintenance contracts — the part of your turnover that doesn’t start from zero every month.

Conclusion

Choose the model based on how much of the project is unknown, not on what the client asked for. Write down in the proposal what’s out of scope. And track your hours — it’s the only thing that makes your next price more accurate than the last.