The hardest part of my first automation build was not the build. It was the sentence I had to say out loud afterwards, the one with the price in it. I had the technical answer long before I had the commercial one, and the gap between those two things nearly cost me the work.
I priced my hours because hours were the only thing I could see
My first instinct was the obvious one. Count the hours, multiply by a rate, add a bit for the parts I would probably get wrong. It felt safe because it felt provable. If anyone challenged the number I could point at a timesheet and defend it line by line.
The problem is that this prices the wrong thing. An hourly quote says: here is what my time is worth. The client is not buying my time. They are buying the absence of a problem they have been carrying for years. Those are not the same product, and the second one is worth far more than the first.
There is a nastier consequence too. When you bill by the hour, getting faster makes you poorer. Every improvement to my own tooling, every reusable piece I built, every lesson from the last job, all of it reduced my invoice. I had accidentally designed a business that punished me for getting better at it.
The question that changed the number
The thing that reframed it was not a pricing course. It was a question I started asking in the first meeting, and now ask in every one: what does this cost you today?
Not what do you want to spend. What is it costing you right now to keep doing it the way you do it. Hours a week, per person. Errors that get caught late. Invoices that go out slow and get paid slower. Deals that go quiet because nobody followed up in time. Once an owner starts adding that up out loud, something shifts in the room. They stop hearing a cost and start hearing a comparison.
That is the whole basis of the Business Autopsy I now run before quoting anything, and it is why I stopped guessing. The number is not invented, it is derived. I wrote about what one of those sessions actually looks like in what a 4-hour Business Autopsy looks like.
What I got wrong, plainly
Three mistakes, and I would make all three again if nobody had told me.
I quoted too fast. Someone described a problem and I gave a number in the same conversation, because saying "let me come back to you" felt like weakness. It is not weakness. It is the only way to quote something you actually understand.
I priced the build and forgot the life. An automation is not a delivery, it is a thing that runs. It needs watching, fixing when an API changes underneath it, and adjusting when the business shifts. I priced a handover and inherited a commitment, which is a very expensive way to learn the difference between a project and a system.
I discounted to be liked. When a number lands in silence, the instinct is to fill the silence by making the number smaller. Every time I did that, I taught the client that my first price was decoration. The silence is not a rejection. It is a person doing arithmetic.
What I would tell someone about to quote their first build
Price the outcome, not the effort. Work out what the problem costs to keep, then position the fix honestly against it. If you cannot describe the cost of the status quo, you are not ready to quote yet, and neither is your client ready to buy.
Write down what is included and, more importantly, what is not. Scope written after a disagreement is a negotiation. Scope written before it is a document.
Separate the build from the running of it. They are different products with different shapes, and pretending otherwise means one of you is going to feel cheated in month four.
And let the number sit. The first real yes I got came after a pause long enough that I nearly talked over it. I did not, and I got the work at the price I asked. I have written about the flip side of that too, the first client who said no, because both outcomes teach the same lesson: the price you can defend calmly is the price you should have asked for.
Frequently Asked Questions
Should I charge hourly or fixed price for automation work?
Hourly is easy to defend and easy to lose money on, because efficiency reduces your own invoice. Pricing against the outcome ties what you earn to what the client gains, and it rewards you for getting better rather than slower.
How do you work out what an automation is worth to a client?
Start with what the current process costs them: hours per week, error rates, delays in getting paid, opportunities lost to slow follow up. That figure is the client's own, not yours, which is exactly why it holds up in the conversation.
Why quote after the meeting instead of during it?
Because a number given in the room is a guess dressed as confidence. Going away, mapping the actual work, and coming back with something reasoned gives you a price you can defend without flinching.
Should ongoing support be part of the build price?
No. A build is a delivery and support is a commitment that runs for years. Fold them together and someone ends up resentful. Quote them separately so both sides know what they agreed to.
What do you do when a client goes quiet after hearing the price?
Nothing. Let the silence run. Most of the time the person is doing arithmetic, not rejecting you. Discounting into that silence teaches them your first number was never real.
If you are trying to work out what your current way of doing things actually costs, before anyone sells you a fix for it, that is the exact job a NexBDM Business Autopsy does.