Alright, week 7.
Mostly business as usual. Some product work, meetings with potential clients and still creating content. I am also happy to report that the time blocking method from l week 3 is still going strong.
The more interesting news is that last week’s in-person meeting turned into a real proposal this week. Writing the reply made me realise how much trust my usual pricing model asks from a new client.
A smaller first bet
Until now, I have generally offered fixed-fee development followed by a retainer for any updates or new features.
My theory, and one that has worked with previous clients, was that a fixed fee made the cost predictable. If the work took more time or effort than expected, I ate the cost on my end. The client knew what they would pay, with no hidden costs.
But the last few weeks have taught me that a fixed fee can still feel risky from the client’s perspective, especially if it is our first time working together.
Let’s say you were the client.
You’ve reached out to me, we’ve gone back and forth over email and agreed to a call or even an in-person meeting. The meeting goes well. I understand what you need and we both come away with a good feeling.
Then, a week after sending me some sample models and files, you receive a proposal that says the automation will cost $10,000.
Now you have to decide whether the value is worth that cost. You also have to trust that I can deliver the tool you want, even though we’ve never worked together before. And how sure are you that this tool is what you need in the first place?
Even after a good meeting, that is a big first bet.
In the past few weeks, I tried to close that gap by doing deeper unpaid discovery. I spent more time clarifying the problem and working out the likely solution before sending a proposal.
That makes the scope clearer, but the final jump is still there. The client still has to decide whether the $10,000 is worth it, while I might spend days working through a proposal that gets rejected.
Writing this week’s proposal made that gap hard to ignore.
So, I am trying capped hourly work, something I was against from the beginning.
I estimate how many hours the work should take and agree on a maximum with the client. If it takes less time, they only pay for the hours I used. If it looks like I will exceed the cap, we stop and talk first.
I have written before that the hourly rate model is a poor proxy for value. I still think that is true. But it is a useful proxy for effort, and everyone understands it.
Fixed pricing still has a place. For a first engagement, though, capped hourly work gives the client a ceiling without asking them to pay for the whole ceiling if the work takes less time. It also means I can take on smaller scripts and automations that do not need to become full-blown applications.
It feels more like becoming a client’s automation partner. We can start with one piece of work, learn how we work together and decide where to go next.
I don’t know if this will work long term, or even short term. But I won’t know until I try.
Alright, thanks for reading.
Onward to week 8.
Thanks for reading
Subscribe to CodedShapes to get more articles like this delivered to your inbox
Work with me: https://codedconstructs.com/contact/
Resources on Computational Design: https://www.codedshapes.com/p/scripository