E-mail:
jsem@patrikpilous.cz
For years I have been reviewing and writing briefs for developers at my clients. I am not a developer, I am an SEO and marketing consultant. But I am the one who defines what needs to be done, who then signs it off and who defends it in front of the client. So I sit exactly where the quote meets reality.
Since I have been writing development briefs and specifying how things should work for around 10 years, I have built up a complete picture of how technologies talk to each other, what is easily possible and how much it will cost. Not for everything, but for a large share of things around e-shops and websites.
And over the past few months something has been happening there that I would not have expected.
Where my limit is today
Although I already build production changes and plugins for clients (dozens of them by now), I still leave more complex work to developers. It is neither humility nor fear. It is a division of labour that makes sense.
I can handle things myself when they have a clearly defined scope and a risk I can carry: template changes, small plugins, data processing scripts, dashboards on top of APIs, feed generators, one-off migrations. For that kind of work, Claude Code today is faster than the whole process of briefing, quoting and approval.
Where I stop: anything that touches the core of an e-shop, anything that has to run for years, anything that could go down in peak season, anything that handles payments or personal data, and anything where you need to know the history of the system and the decisions someone made in it five years ago. There I want a person who stands behind it.
And I will admit one more thing. The conversation with a developer often produces a better result than the one I brought in the brief. Someone tells me that what I want can be done differently and more simply, or that half of the solution is already in the system. I am happy to pay for that. That is the part that is still rare.
The pattern that keeps repeating
It looks like this.
- I submit a request or clarify a client’s request.
- I get an hour estimate from the developers that is inflated, often several times over, and for some items by a whole order of magnitude.
I am not talking about a difference of ten or twenty percent, which is not worth discussing. I am talking about items where I know how much work they involve, because I did the same class of work myself last week.
Why is that? I have three hypotheses. The first two drive me mad, the third one I had to admit to myself.
A) The developer does not use AI
Which I find hard to believe these days. But I am in a bubble, and it is fair to admit that. I am someone who has Claude Code open every day, and I tend to assume everyone does. They do not.
If they do not use AI, they quote as if it were 2024. An estimate based on person-hours in which code is still written by hand, documentation is still looked up by hand and tests are still rewritten by hand. The price is honest. I am just paying for their decision not to change tools.
It is like wanting to dig a hole for a swimming pool and a company quotes you an hourly rate for a guy who will hack away at it with a shovel. The price is calculated correctly. That man really will dig for two weeks and really does deserve to be paid. It is just that two streets away there is an excavator standing idle.
And here is the part most people skip with this analogy: the difference is not paid by the one who chose the shovel. It is paid by the one who chose the company without knowing there was a choice.
There are legitimate reasons why someone does not use AI. An NDA and sensitive code that must not be sent to the cloud. A regulated environment. Code so specific that a model does more harm than good. A personal principle, which everyone has a right to.
I respect all of that. I just want it to be visible in the quote, because it is information about the price. Not about the quality.
B) The developer uses AI and does not say so
The mechanics are simple and tempting.
The estimate stays the old one. Let us say 40 hours. The work is done in 8, of which 4 are lost to back-and-forth over approvals. 40 are invoiced. The client has no way of telling the difference, because they are buying an output, not a process. Nobody counts how many lines were written by a person and how many by an agent.
I have heard two defences of this, and both are interesting.
“You are paying for the result, not the time.” I agree. But then why does the quote say “40 h · rate”? If it is for the result, let it be for the result: a fixed price, a definition of done, end of story. This argument cannot hold only when the time has shrunk and stop holding when the work drags on and an addendum arrives.
“The investment in tools and know-how is mine, not yours.” This one is stronger and in principle I agree with it. Anyone who has learnt to steer an agent, keep the context, write a brief so that the output is not rubbish and, above all, recognise when the model is lying to them has a real skill that is worth paying for. But that is a reason for a higher rate or a higher price for the result. It is not a reason to keep an hour estimate that no longer applies and hope nobody asks.
The difference between “I have better tools, so I am more expensive” and “I have better tools, so I keep the difference” is one sentence in the quote. The one nobody puts there.
C) The hypothesis I had to admit to myself
While I stuck with those two, I was quite pleased with myself. Then I tried putting myself in their place and stopped being pleased.
Part of the quote may be neither backwardness nor a rip-off. It may be the price of everything that happens around the work and that I do not see in my own estimate.
The overhead around it. I wrote it into my own example: of the eight hours, four are lost to back-and-forth over approvals. Those are real hours. A brief that changes along the way. Three rounds of feedback. A test environment that differs from production. A client who goes silent for a week and then wants it on Friday. A deployment that has to be scheduled outside peak hours.
The risk buffer. A fixed or semi-fixed price means the supplier carries the risk that the work turns out to be more complicated. With Claude Code I estimate the happy path, because a prototype is allowed to fail. They estimate the unhappy one too, because their version is not allowed to fail.
Price as a filter. Sometimes a high quote is not really a quote. It is a polite “I do not want to do this”: a small job in someone else’s system, where taking over the context is more work than the job itself. That is understandable.
Responsibility I do not have. When my plugin breaks, I fix it at night and nothing bad happens to anyone. When their integration breaks, it is handled as an incident. That is a different service and it has a different price.
I have to subtract all this from every quote before I start complaining. Sometimes, after subtracting, it turns out the quote was fine and it was my estimate that was off. But often, after subtracting, there is a difference left that none of the above explains.
“We can try it experimentally”
When I then timidly ask whether it could be done with the help of Claude Code if I supply the inputs, the most common answer I get is that they can try it experimentally.
It took me a while to notice how much that sentence contains.
It means it is not used in day-to-day work. It means it is seen as a risk, not a tool. And above all, it means the cost of the experiment will not be borne by the one doing the experimenting.
And on my side it is not a bold proposal at all. It is not “let the AI write it”. It is “here is a brief written out in detail, here is a description of the data model, here is an example of input and output, here is a template of a similar thing that already works elsewhere”. Half of the work a developer usually does at the start is already done. The rest is their expertise, and that does not disappear just because an agent writes the code for them. It shifts into the decision about what to let through.
The best answer I have ever had to that question went roughly like this: “Yes, I use it every day, but I do the review by hand and I do not trust it with these three things.” That is a person whose quote I trust, even when it is higher.
What I am not saying
That “Claude will knock it out these days” and development should cost a tenth. That extreme is just as costly for the client as an overpriced quote, it only shows up later.
Architecture has not got cheaper. An agent will not make good decisions about how to split a system and what should live where, because it does not know the company’s context, the history of the system or the people who will work in it.
Review has not got cheaper. Generated code looks good, and in nine cases out of ten it is good. The tenth one goes down on Black Friday.
Responsibility has not got cheaper. When it does not work, I call the supplier. I do not call the model.
Domain knowledge has not got cheaper. A developer who knows Shoptet knows what its API cannot do and what breaks when a template is updated. A model finds out by trial and error, at my expense.
The value has moved from producing code to making decisions about code and standing behind the result. It has not disappeared. And anyone who can sell that has no reason whatsoever to hide behind hours.
How I deal with it
Four things that work for me.
I ask about tools directly. “Do you use AI assistants, and how?” The answer does not tell me the price. It tells me whether the estimate is from this year or from 2023.
I buy the result, not hours. A fixed price, a definition of done, milestones. That turns the whole argument about hours into something that is no longer my problem. The supplier is motivated to be fast, because speed is their profit, and I know how much I will pay.
I test the estimate with a prototype. When I do not know whether a quote is realistic, I build a rough version myself. Not to deliver it. To find out where the work is actually complicated. Usually it turns out the complexity lies somewhere other than I thought. Sometimes it turns out it really is three weeks and the quote was fair.
I write briefs so they can be handed to anyone. Data model, input, output, edge cases, what must not break. A side effect: a good brief is exactly what an agent needs, and also exactly what tells a good developer they are talking to someone who knows what they want.
And of course, credit to the exceptions
I have people around me who price fairly, tell me what tools they will use, and pass the speed gain back to me, so I get more work or get it sooner for the same money. I keep working with them, and gladly.
The question is not “are developers expensive”. The question is that we keep selling a unit that no longer tells you anything about the size of the work. The hour.
And this problem is not someone else’s. It is mine too. An SEO audit that took me three days two years ago now takes an afternoon. So I have to ask myself the same question about my own prices. The answer I ended up with: do not bill for time, bill for output, and reinvest the time I have gained into the depth of the work, not into free time of my own that the client does not know about.
I see this as a new chapter that I come across more and more often, and I have not fully worked it out yet. So I am happy to hear other views and experiences, from both sides of the table.
