Our Harvest bill went from $90 a month to $600 a month. Same team, same projects, same work as the month before. A very different number at the bottom of the invoice.
We weren't alone. Other agency owners we know started comparing bills and seeing the same thing. Nobody had suddenly doubled their team or dramatically changed how they worked. The bill just moved.
I could have written the angry LinkedIn post. Screenshot the invoice, complain about SaaS pricing, collect a few sympathetic comments and move on. I've read plenty of those posts. I have never once seen one change a price.
I've read plenty of those posts. I have never once seen one change a price.
So we built something instead.
Somebody put a meter on the tap
Harvest has been one of those boring, dependable tools that agencies quietly build their businesses around. We've used it for years for time tracking and invoicing, and it has largely just done its job.
Its pricing model changed from predictable per-seat pricing toward a model that also charges based on usage. Projects, tasks, clients, invoices and other activity can now affect what you pay. It's a bit like somebody putting a meter on your kitchen tap. You didn't start using more water. Nobody moved into the house. You just woke up one morning and discovered that something previously included in the rent was now being measured.
For us, that meant roughly $90 a month became $600 a month ($1,080 a year to $7,200 a year).
I run a product studio, so I have a hard time leaving problems like this alone. This one had all the right ingredients. It was a real problem happening right now, lots of people were asking the same question, and most importantly, it was solvable.
Nobody needed another forty-page analysis of SaaS pricing or my hot take on software acquisitions. They needed to answer a much simpler question. What is Harvest actually going to cost me now?
Two days later
We scoped the idea down to one job. Help someone understand what the pricing change could mean for their business and give them some alternatives.
That's how harvestsomesavings.com came about. Two days from idea to a real product on a real domain.
We didn't build a platform. We built a bathroom scale. Step on, get a number, decide what to do next.
We didn't build a platform. We built a bathroom scale.
The site includes a pricing calculator that compares the old pricing against an estimate of the new pricing, along with alternatives to Harvest, a migration guide and answers to the questions people were already asking. Nothing particularly complicated, and nothing that didn't directly help answer the original problem.
That constraint is probably why we got it out the door.
Then we got it wrong
Shortly after launch, a friend who runs an agency put his real numbers into the calculator. Twenty-nine seats and 173 active projects. The estimate looked ridiculous.
He was right.
Our model worked reasonably well for smaller teams but became too aggressive as usage increased. Harvest doesn't publish all of the underlying usage rates, so we were modelling from reported bills and the information available to us. The math was internally consistent, but our curve was wrong at scale.
So we changed it.
We rebuilt the model, checked it against real examples and pushed the fix. Because the site was already running on an automated deployment pipeline, the correction went from feedback to live almost immediately.
The advantage wasn't being right on day one. It was how quickly we could stop being wrong.
The advantage wasn't being right on day one. It was how quickly we could stop being wrong.
I think this is one of the biggest misunderstandings about moving fast. Fast doesn't mean careless. It means making the smallest useful thing you can, putting it in front of real people and learning what you couldn't possibly learn sitting around a conference table.
There is an argument that we shouldn't have shipped the calculator until the math was bulletproof. I don't really buy that. The math is never going to be bulletproof when you're modelling a pricing structure where the vendor doesn't publish all of the underlying rates. The fastest way to find the flaw was to put it in front of somebody with a real invoice and let them challenge it.
Version one being wrong wasn't the problem. Being slow to fix it would have been.
Shipping before the math is bulletproof is one dispatch of many. The Signal ships what we're learning — monthly, short, no filler.
Fast isn't the same as careless
There was another obvious issue we had to account for. We were an annoyed customer building a tool about the company that had annoyed us. That's a bias, and pretending otherwise would have been ridiculous.
So we tried to build against it. Claims about Harvest's pricing are qualified because we're working from reported behaviour, available information and our own experience rather than a complete published rate card. Affiliate relationships are disclosed. We tell people pricing changes and that they should confirm it at the source.
We also didn't build a Harvest hate site. Harvest is a good product that a lot of businesses have relied on for years. The company that owns it made a pricing decision that some customers, including us, didn't like. Those are two different things.
You can move quickly and still do the work properly. Claims need sources, assumptions need to be clear, commercial relationships need disclosure and when you don't know something, you should say you don't know it.
Speed isn't an excuse to lower the bar. It just shortens the distance between assumption and reality.
Speed isn't an excuse to lower the bar. It just shortens the distance between assumption and reality.
The metric I care about
None of this is really about Harvest. It's about the distance between noticing something and shipping something.
Most organizations measure that distance in months or quarters. I think it is becoming one of the most important competitive advantages a company can have, because the tools required to design, build and deploy software have become dramatically more accessible. AI has compressed that distance even further.
Which means the bottleneck increasingly isn't technology. It's deciding what is worth building, cutting away everything that doesn't matter and getting something useful into the hands of real people.
The pattern isn't particularly complicated. Spot the problem while it's relevant. Decide what actually needs solving. Build the smallest useful version. Put it in front of people. Learn from what happens, fix what you got wrong and repeat.
That's the muscle we're trying to build. harvestsomesavings.com is just the latest rep.
Your next product idea probably doesn't need another pitch deck. It needs to exist.