Fixed price, fixed scope: how I run automation projects
Hourly billing rewards slow work. So I price the outcome, not the hours — and both scope and price are known before we start, and don't move afterwards.
Hourly billing has a conflict of interest baked in: the longer the project runs, the more the contractor earns. The client carries all the risk that something takes three times longer than promised in the first meeting.
I work the other way round.
Scope first, price second
Before any quote we map the process: what goes in, what must come out, where the exceptions are, who uses it and how often. That is usually one or two meetings plus a short document. Only then does a price appear.
The scope document is deliberately plain — it has to be readable by the person who will use the tool, not only by the IT department.
The price is fixed
If something takes me twice as long as I estimated, that is my problem, not yours. You know the number up front and budget for it once.
What if a new idea comes up mid-project?
It nearly always does — and that is a good sign. But new things do not quietly slip into the current scope. They go on a list, and once the current stage is closed we decide together what happens next and what it costs.
That is what keeps a first delivery measured in weeks instead of dissolving into months.
Weeks, not months
A typical first stage runs two to six weeks from first contact to a working tool in your hands. Not because of shortcuts — because the scope is deliberately small and closed.
One thing that works on Wednesday beats ten things that will be ready “next quarter”.