How to know your helper
is earning its keep.
Most people do not measure whether their new software is actually helping. Three numbers, once a week, five minutes. You will know within a month.
You paid a builder. The helper is live. It is doing something, but you are not quite sure if it is actually saving you time, or just making you feel modern. This is one of the most expensive unexamined assumptions in small business software: that because the tool is running, it is working.
Here is how to find out in five minutes a week. If after a month the numbers say no, you will know to change something. If they say yes, you will have the evidence to expand.
The three numbers.
You only need three. Any more and you will not keep it up. These three, tracked honestly, tell you almost everything.
- Hours back. Rough estimate, not a stopwatch. “About four hours this week” is fine. The first month’s number is low (you are still training it). By month three it should be stable.
- Mistakes caught. How many times did you have to fix something the helper got wrong before it went out the door? The number matters less than the trend. Week on week, it should be going down.
- Moments of relief. Write a one-line note each week: a specific moment when you noticed the helper made something easier. “Finished at 5pm Friday instead of 9pm.” “Did not panic when the quote request came in late Sunday night.” If you cannot think of one, the helper is not landing.
The weekly check-in.
Once a week, same day, same time. Friday afternoon works for most people. Open your notebook. Write:
Hours back this week: [rough number]
Mistakes caught: [rough number]
One moment of relief: [one sentence]
Close the notebook. That is it. If it takes more than five minutes you are overthinking it.
At the end of each month, read the last four entries. Trends, not individual weeks, are what matter. An up-and-down pattern is normal. A flat or declining pattern is a signal.
The break-even maths.
Take the total cost of the build (what you paid the builder, plus running costs so far). Divide by your hourly rate. That is the number of hours the helper needs to save before it has paid for itself.
A $2,450 build, at $75 per hour, breaks even at about 33 hours saved. A helper saving three hours a week gets there in roughly eleven weeks. Write this number down the day the helper goes live. Check progress monthly. Most small business helpers break even in the first two or three months. If yours has not by month four, something is wrong and it is worth a conversation with the builder.
When to kill a helper that is not working.
Helpers fail for reasons. Usually fixable. But if you see these signs three months in, something is fundamentally misaligned:
-
You do not use it.
Not “used it less this week.” Truly do not open it. You have a better manual workaround, or the helper does not fit your actual day. Stop paying to run it.
-
You stopped trusting its output.
You re-check everything it produces, always, no matter what. You are doing the task twice. Worse than before the build. Either the helper is wrong, or the task turned out not to be automatable. Either way, close it.
-
It works but you do not care.
You saved the time. You filled it with more of the same work. You are no happier. The problem is not the helper; the problem is what you built to save time on. Build a different one.
Killing a helper is not a failure. Keeping a bad one running out of sunk-cost loyalty is the failure. Most builders, including me, would rather you turn off a helper that is not landing and build a different one that is.
The short version.
Three numbers. Five minutes. Once a week. After a month you will know whether you built the right thing. After three months you will have the maths to decide whether to expand, tweak, or kill it. This is the cheapest insurance policy you can take on a software investment.
Related: what it costs to run · Back to the guide · hello@solocmo.ai