Pricing consulting services is one of those things that looks simple until you try to do it. You think, how hard can it be, just pick a day rate. Then you discover you are leaving significant money on the table, or you price yourself out of work you actually wanted, or you get the rate right but structure it wrong and end up with cash flow nightmares.
I have been consulting and freelancing alongside running my own businesses for over a decade now. Across Dynamics 365 architecture work, software development, and business consulting, I have tried most of the models going. The pricing mistakes I made early on cost me real money and real opportunities. Here is what I actually learned.
The day rate trap every developer falls into
Most technical freelancers start with a day rate. It is the simplest model to understand and it is what clients expect. But the day rate model has a fundamental problem: it creates a direct link between the hours you work and the money you earn. That sounds fine, right up until you get more experienced.
The more skilled you become, the faster you solve problems. A junior developer might take three days to implement something. You do it in half a day. If you are on a day rate, you just lost two and a half days of income. Your expertise literally costs you money. That is a bloody awful incentive structure and it gets worse the better you get.
This is the core of why experienced consultants eventually move away from time and materials. The value you deliver has almost nothing to do with the time you spend.
How to actually set your day rate
Before we get to the better models, you still need a day rate for projects where clients insist on it or where the scope genuinely cannot be defined upfront. So here is how to set one properly rather than just guessing.
Start from what you need to earn. Not what sounds impressive. Not what your mate charges down the pub. What do you actually need to cover your costs, save adequately, and have a decent life? Factor in everything: no sick pay, no holiday pay, no employer pension contributions, gaps between contracts. As a rule of thumb, you need to bill at roughly double what an equivalent salary would imply to end up in the same financial position as a permanent employee. Most people do not account for this properly.
Then look at the market. Find out what comparable people charge in your specialism and geography. If you are doing Dynamics 365 architecture work in the UK, you should know what that market pays. If you are a .NET developer doing product work, same thing. Rates vary enormously by specialism, seniority, and client type.
Then take the higher end of what you find and add 20 percent. Most developers undersell themselves badly. The imposter syndrome is real and it costs you real money every single day. If you are worried you are too expensive, you are probably about right. If nobody ever pushes back on your rate, you are definitely too cheap.
The models that are actually worth using
Once you have the baseline sorted, you need to think about whether a day rate is even the right model for each engagement.
Retainer agreements
Retainers work brilliantly for ongoing advisory or support work. A client pays you a fixed monthly fee to be available for a certain amount of time or a certain scope. You get predictable income. They get predictable costs and guaranteed access to you. These are genuinely the best arrangement going for consultants who want stability without a permanent role.
I run several retainer arrangements across my consulting work at the moment and they have transformed my cash flow compared to project by project billing. The key is being utterly clear about what the retainer covers and what falls outside it. Vague scope kills retainers. Put in the work upfront to define the boundaries and you will have a much better time.
Fixed price project work
Fixed price is higher risk but higher reward. You quote a fixed price for a defined deliverable. If you deliver faster than expected, you make more per hour. If it takes longer, you eat the difference. The trick is getting good at scoping and being explicit about what is and is not included.
After doing enough fixed price projects you develop an intuition for where the hidden time goes. Discovery work the client said would be straightforward. Integrations with legacy systems nobody properly documented. Stakeholder sign off that takes three times as long as the contract allows. Build all of that contingency into your quote from the start. Do not be optimistic with fixed price. Be accurate.
Value based pricing
This is the most powerful model but also the hardest to implement well. You price based on the value your work delivers to the client, not the time it takes you. A Dynamics 365 implementation that saves a business three people worth of manual processing is worth a very different conversation than six weeks at your day rate.
This requires you to understand the client's business well enough to actually quantify the impact. Not every client will engage with this model. Many procurement teams are just not set up for it. But the ones who do engage with value based pricing are almost always better clients, because they are buying outcomes rather than hours.
The conversations you actually need to have
Pricing is uncomfortable because it involves money and most of us were not raised to talk about money directly. Get over it, because avoiding the conversation does not make it disappear. It just means you end up with misaligned expectations and resentment on both sides.
Be explicit about your rate before you do any work. Get it in writing. Scope the engagement clearly and agree what happens when scope changes, because it always does. I do not start work without a signed proposal or at minimum a clear written agreement. Not because I am paranoid about clients, but because clear agreements prevent the uncomfortable conversations later.
Anyone building their consulting practice alongside other work will find I go into the process in much more detail in The 28 Day Startup. The short version though: treat your consulting like a business, price like a business, and protect yourself legally like a business. Not like a favour you are doing for someone.
What to do when someone says you are too expensive
You will get pushback. Clients will tell you they have found someone cheaper. Sometimes that is true. Sometimes it is a negotiating tactic. Sometimes the cheaper option genuinely is what they need and that is fine.
The thing about price objections is this: if someone is choosing a technical consultant purely on price, they are usually not the client you want. Good clients hire on track record, expertise, and fit. They negotiate fairly but they are not trying to squeeze every penny out of you. A client whose first question is "can you do it cheaper" tends to have problems that go well beyond pricing.
When I am too expensive for someone, I say so honestly and explain what the difference in price reflects. Sometimes they come back when the cheaper option does not work out. That happens more often than you might think, and those are often the best client relationships because the person already knows what they are getting.
The mindset shift that actually matters
The single biggest pricing change I made was stopping thinking of myself as a developer who works for clients and starting to think of myself as a business that solves problems for other businesses. That sounds like corporate nonsense but it genuinely changes how you approach every pricing conversation.
A developer working for a client accepts whatever the client offers and feels lucky to have work. A business solving problems for other businesses charges what the solution is worth and walks away from work that does not meet that threshold.
Get comfortable walking away from work that does not pay what you are worth. Every cheap job you take fills the time you could spend finding a well paid one. It is a hard habit to break, especially early on. But it is the single best thing you can do for the long term health of your consulting practice.
The market for skilled technical consultants who can actually get things done is not as competitive as you might think. There are a lot of people selling development hours. There are far fewer who understand the business context, can communicate with stakeholders, and reliably deliver what they promised. If you are that person, charge accordingly.
