I built a $19.99 tool for a pricing problem I kept seeing in bookkeeping
I built a $19.99 tool for a pricing problem I kept seeing in bookkeeping
I noticed a recurring problem with fixed-fee bookkeeping clients:
The monthly fee stays the same, but the workload doesn't.
A client might start at $1,200/month and take 15 hours of work.
Then, over time:
- More emails
- More meetings
- More revisions
- More requests
- More administrative work
The client is still paying $1,200.
But the effective hourly rate has dropped.
The difficult part isn't calculating the hourly rate.
It's deciding when a client has become unprofitable enough to justify a pricing change.
So I built Reprice, a small decision-support tool for professional bookkeepers.
You enter things like:
- Current monthly fee
- Actual time spent
- Direct costs
- Target effective hourly rate
It then helps you determine whether to:
Keep → Review → Reprice → Repackage → Exit
It's deliberately simple. No subscription, no complicated setup, and no AI.
The price is $19.99.
I'm not trying to build a huge SaaS around this. I'm trying to find out whether this is actually a useful problem to solve.
So I'm particularly interested in hearing from bookkeepers:
How do you currently review whether a fixed-fee client is still profitable when their workload changes?
Do you use a spreadsheet, time-tracking software, accounting software, an internal process, or do you mostly handle it when the problem becomes obvious?
I'd especially appreciate hearing what you currently do and what's frustrating about that process.
The fixed-fee trap is so real: the price only makes sense if you keep watching effective hourly rate as scope and workload change. A useful workflow is to set a review trigger (for example, after two heavier months) and renegotiate around the actual work, not just the original deliverables. Making that review visible to the client also turns a painful pricing conversation into a predictable process.
This is a very real fixed-fee problem: the price stays still while scope and context quietly expand. I’d make the tool’s output operational, not just diagnostic—show the implied effective hourly rate, flag the month the engagement crossed the agreed scope, and generate a client-facing review script with three options (re-scope, raise the retainer, or move to time-and-materials). That turns a painful conversation into a repeatable process. Are bookkeepers using it before renewal, or only after a project has already gone underwater?
A useful companion to the monthly review is a simple “why did this change?” log: scope, response time, and client mix. It helps separate a one-off spike from a new baseline before you propose repricing. I’d make the default output a one-page conversation summary, not just a score.
The one-off spike vs. new baseline distinction is particularly interesting. I can see how repricing based on a single unusual month could be premature.
I'm also interested in the conversation-summary idea. When you say scope, response time, and client mix, are those things bookkeepers typically document already, or would the tool need to help them build that evidence over time?
The scope-drift check feels like the right wedge. I’d track one extra thing alongside hours: unplanned requests by type. That gives you a concrete agenda for the pricing conversation instead of making it feel like a judgment call. Do bookkeepers usually review this monthly, or only once the margin already hurts?
That's the timing question I'm trying to understand now. If scope drift is happening gradually, I'm interested in whether firms actually have a regular review point or only act once the margin becomes painful.
The idea of tracking unplanned requests by type is particularly useful because it could make the pricing conversation much more concrete.
One lightweight approach is a monthly “scope drift” check: compare hours, request types, and turnaround time with the original baseline, then log the top two sources of variance. That creates a concrete agenda for a pricing or repackaging conversation without requiring perfect time tracking. A short pilot with a few clients could also reveal which proxies predict margin erosion best.
The monthly scope-drift check is an interesting angle. I especially like the idea of identifying the specific sources of variance rather than trying to measure everything perfectly.
I'm curious whether bookkeepers actually review those changes monthly in practice, or whether it usually only becomes visible once profitability starts to hurt.
That’s a fair concern. I’d make it a lightweight monthly exception report—only flagging hours, request types, or turnaround that move materially from baseline—so it takes minutes rather than becoming another timesheet. If the signal is weak, a quarterly review or renewal checkpoint may be more realistic; a short pilot should show which cadence actually changes pricing decisions.
That distinction between monitoring everything and only flagging material exceptions is useful.
The part I'm most interested in is your point about what actually changes the pricing decision. In practice, what usually becomes the trigger: a sustained increase in hours, repeated out-of-scope requests, slower turnaround, or something else?
I’d treat sustained hours as the primary trigger, with repeated out-of-scope requests as the leading indicator. Slower turnaround is useful corroboration, but can be noisy. I’d flag it when two signals persist for a couple of review cycles rather than reacting to one unusual month, then check whether the cause is seasonal or a genuine scope change.
That distinction between a leading indicator and a lagging one is useful.
The two-cycle rule also makes sense for avoiding false positives from seasonal work. In practice, how do bookkeepers usually establish the original baseline for a client — is it based on the initial scope/package, historical hours, or something else?
That makes sense. I’d start with a baseline from the original scope/package plus a short lookback of actual tracked hours where available, then treat it as adjustable rather than fixed. The two-cycle rule seems like a good guardrail against seasonality.
Exactly. I think the key is separating a temporary spike from a persistent change in the client economics.
How do you usually handle it when the tracked hours aren’t reliable or the scope has changed significantly since the original package? Do you rely more on time estimates, scope changes, or other signals?
The hard part you named is the right one, and I think there is a harder one underneath it.
Your tool needs "actual time spent". That is the one number a fixed fee bookkeeper usually does not have, because the whole point of a fixed fee is that you stop tracking time. So the input the decision depends on is the input least likely to exist. People will type a guess, and the guess will be optimistic in exactly the direction that hides the problem.
Two ways round it. Estimate from proxies they already have: email threads, meetings, revision rounds, all countable from an inbox and a calendar. Or have the tool ask for a two week time sample on one suspect client before it gives a verdict.
Either way, the most valuable output might not be the Reprice or Exit label. It might be "here is how far off your guess was". That is the moment someone actually raises their price.
That's a good point. The actual-time input is something I'm specifically trying to validate, because if bookkeepers are estimating rather than tracking, the result can be misleading.
The proxy approach is interesting too, especially unplanned requests, meetings, and revisions.
For a fixed-fee client whose workload has increased, do you usually see bookkeepers tracking any of those signals already, or is it mostly based on intuition?
The calculation seems easy; the harder part is acting on the result. Have bookkeepers used Reprice to actually change a client's fee or packaging, or is the bigger hurdle still getting comfortable making that conversation?
That's exactly the part I'm trying to validate now.
Reprice is designed to make the decision clearer — keep the client, review the pricing, change the scope/package, or consider exiting — but I don't yet have enough real-world usage to claim that bookkeepers have used it to actually change a client's fee.
The conversation itself may be the harder part, which is why I'm also interested in how bookkeepers currently handle that step.
When you say "getting comfortable making that conversation", do you mean the actual client conversation, or deciding internally that the economics justify a price change?
That client-pricing decision is the interesting part. If you’re open to it, what’s the best email to reach you on?
a.koumad.pro@gmail.com
Thanks! I’ve just sent it over.
Looking forward to hearing your thoughts whenever you have a chance.