1
93 Comments

When is a client change actually worth repricing?

I've been looking at how small service businesses handle existing clients on fixed fees.
One thing keeps coming up:
A client changes.
More transactions.
More emails.
More meetings.
A new service.
More revisions.
But not every change should trigger a price increase.
A temporary spike is different from a structural change.
A few extra hours one month is different from a permanently larger scope.
And "the client is taking more time" is often too vague to make a pricing decision confidently.
So I'm increasingly interested in the decision point before repricing:
What evidence is enough for you to say: "This has changed materially — it's time to review the price"?
Is it:
• a % increase in workload?
• additional services?
• transaction volume?
• hours consistently exceeding expectations?
• repeated scope creep?
• something else?
I'm particularly interested in how founders and service businesses actually make this decision in practice — not what the ideal process looks like on paper.

on September 23, 2026
  1. 1

    For me, repeated scope changes are a bigger signal than a specific percentage.

    If a client keeps adding small things, I think that's usually when the original scope stops being a useful reference point.

    I'd probably track the requests separately from the actual hours. That way you can see whether it's a one-off busy period or the client is consistently asking for more than what was originally agreed.

    The awkward part is deciding when to actually bring it up with the client. Waiting until the end makes it much harder.

  2. 2

    I think the repeated pattern is more useful than a specific percentage. If the workload stays above the original scope for 2-3 billing cycles, that feels like a stronger signal to review pricing than a single unusually busy month. I had also separate “more work” from “more value” because the latter can sometimes justify repricing even when the hours haven’t increased much.

    1. 1

      The 2–3 billing cycle point is interesting. Do you treat those cycles as a hard threshold, or more as evidence that the change is becoming structural? And how do you usually distinguish “more work” from “more value”?

  3. 1

    I separate a temporary spike from a structural scope change, then use evidence rather than a vague feeling that the client is “taking more time.” Track the baseline (included volume, revisions, response time, and actual hours). If the work is consistently 20–25% above baseline for two cycles, or a new recurring deliverable appears, that’s a good trigger to propose a new tier or a scoped add-on. A one-off spike can stay a one-off surcharge. For any flat-price offer, reverse-calculate the net you need: with illustrative checkout assumptions of ~10% platform + 2.9% card processing + $0.30 fixed, a $30 gross sale leaves about $25.83 before refunds, tax, ads, or support. State assumptions, check the current schedule, and validate willingness to pay. This keeps repricing tied to scope and margin, not emotion.

  4. 1

    The temporary-spike vs. structural-change distinction is spot on — keeping a month-by-month P&L makes the “this is now the baseline” conversation much less subjective. I keep a free monthly P&L + quarterly tax set-aside spreadsheet here: https://solopreneurpl.com. Do you think you’d want client-level workload evidence tied to the financials, or is a simple 2–3 month threshold enough?

    1. 1

      That’s a good distinction. I’m leaning toward the workload evidence being useful when the financials show that the change is becoming persistent, rather than treating 2–3 months as an automatic rule.

      I’m curious how you’d handle it in practice: would you track client-level hours/scope/requests alongside the P&L, or would the month-by-month financial trend usually be enough to trigger the review?

  5. 1

    Clear and practical, thanks. Did anything surprise you along the way?

  6. 1

    Clear and practical, thanks. Did anything surprise you along the way?

  7. 1

    Clear and practical, thanks. Did anything surprise you along the way?

  8. 1

    Thanks for writing this up. Bookmarking it for later.

  9. 1

    Clear and practical, thanks. Did anything surprise you along the way?

  10. 1

    Interesting approach. What was the hardest part to get right?

  11. 1

    Clear and practical, thanks. Did anything surprise you along the way?

  12. 1

    Clear and practical, thanks. Did anything surprise you along the way?

  13. 1

    Nice work shipping it. What has been the biggest challenge since launch?

  14. 1

    Helpful post. How did you get your first bit of traction?

  15. 1

    Interesting take. Would you still recommend this approach to someone starting today?

  16. 1

    Helpful post. How did you get your first bit of traction?

  17. 1

    Clear and practical, thanks. Did anything surprise you along the way?

  18. 1

    Clear and practical, thanks. Did anything surprise you along the way?

  19. 1

    Interesting take. Would you still recommend this approach to someone starting today?

  20. 1

    Really relatable. How much time do you put into this each week?

  21. 1

    Nice work shipping it. What has been the biggest challenge since launch?

  22. 1

    What made you pick this stack over the alternatives?

  23. 1

    Interesting approach. What was the hardest part to get right?

  24. 1

    This is useful. How are you finding your first users so far?

  25. 1

    This is useful. How are you finding your first users so far?

  26. 1

    Good write-up. What would you do differently if you started again?

  27. 1

    This is useful. How are you finding your first users so far?

  28. 1

    Interesting approach. What was the hardest part to get right?

  29. 1

    Appreciate the honesty here, most people only share the wins.

  30. 1

    Interesting approach. What was the hardest part to get right?

  31. 1

    Clear and practical, thanks. Did anything surprise you along the way?

  32. 1

    Clear and practical, thanks. Did anything surprise you along the way?

  33. 1

    Interesting approach. What was the hardest part to get right?

  34. 1

    Interesting approach. What was the hardest part to get right?

  35. 1

    Clear and practical, thanks. Did anything surprise you along the way?

  36. 1

    Interesting approach. What was the hardest part to get right?

  37. 1

    Clear and practical, thanks. Did anything surprise you along the way?

  38. 1

    Interesting approach. What was the hardest part to get right?

  39. 1

    Clear and practical, thanks. Did anything surprise you along the way?

  40. 1

    Clear and practical, thanks. Did anything surprise you along the way?

  41. 1

    Interesting approach. What was the hardest part to get right?

    1. 1

      Thanks. The hardest part has actually been separating a temporary workload spike from a structural change.

  42. 1

    Clear and practical, thanks. Did anything surprise you along the way?

    1. 1

      Thanks. One thing that surprised me was how often “more work” and “more value” aren't necessarily the same thing.

  43. 1

    Interesting approach. What was the hardest part to get right?

  44. 1

    Clear and practical, thanks. Did anything surprise you along the way?

  45. 1

    Interesting approach. What was the hardest part to get right?

  46. 1

    Clear and practical, thanks. Did anything surprise you along the way?

  47. 1

    Interesting approach. What was the hardest part to get right?

  48. 1

    Clear and practical, thanks. Did anything surprise you along the way?

  49. 1

    Interesting approach. What was the hardest part to get right?

  50. 1

    Clear and practical, thanks. Did anything surprise you along the way?

  51. 1

    What made you pick this stack over the alternatives?

  52. 1

    Interesting approach. What was the hardest part to get right?

  53. 1

    How did you decide this was worth building in the first place?

  54. 1

    Clear and practical, thanks. Did anything surprise you along the way?

  55. 1

    Interesting approach. What was the hardest part to get right?

  56. 1

    Clear and practical, thanks. Did anything surprise you along the way?

  57. 1

    Interesting approach. What was the hardest part to get right?

  58. 1

    Interesting approach. What was the hardest part to get right?

  59. 1

    Interesting approach. What was the hardest part to get right?

  60. 1

    Interesting approach. What was the hardest part to get right?

  61. 1

    Clear and practical, thanks. Did anything surprise you along the way?

  62. 1

    Solid lesson. Which channel has worked best for you so far?

    1. 1

      So far, direct conversations and niche communities have been more useful for learning than broad promotion.

  63. 1

    Good write-up. What would you do differently if you started again?

    1. 1

      I'd probably start collecting real pricing-review triggers earlier instead of trying to define the framework upfront.

  64. 1

    Good write-up. What would you do differently if you started again?

  65. 1

    Nice progress. What is the next thing you are focusing on?

    1. 1

      Right now I'm focusing on turning these observations into clearer decision rules.

  66. 1

    Nice progress. What is the next thing you are focusing on?

  67. 1

    Great breakdown. What feedback have you had from early users?

  68. 1

    Great breakdown. What feedback have you had from early users?

    1. 1

      The most useful feedback so far has been around what actually counts as a meaningful change, rather than just tracking hours.

  69. 1

    Makes sense. Are you planning to charge for it, or keep it free for now?

    1. 1

      I'm testing it as a paid product rather than keeping it free. The interesting question for me now is whether the decision framework is valuable enough to pay for, rather than simply useful.

  70. 1

    What made you pick this stack over the alternatives?

  71. 1

    A lasting shift from weekly batches to same-day requests would be one signal for me. Even at similar hours, more of the week has to stay available. That gives you a specific conversation: keep the original schedule, or agree on the cost of faster responses.

  72. 1

    Interesting approach. What was the hardest part to get right?

  73. 1

    Clear and practical, thanks. Did anything surprise you along the way?

  74. 1

    Clear and practical, thanks. Did anything surprise you along the way?

  75. 1

    Interesting approach. What was the hardest part to get right?

  76. 1

    I’d use a rolling scope-and-margin check: log included hours/transactions/revisions plus direct delivery costs each cycle, compare 2–3 billing cycles, and reprice when contribution margin falls below your floor or scope exceeds a defined band. Example: a $1,000 fixed fee with $300 delivery cost leaves $700 contribution (70%); if the added workload pushes cost to $500, contribution falls to 50%—a quantitative trigger even before hours double. Treat a one-off spike as a change order/surcharge, but a structural change as a new tier or renewal price, with the original baseline documented.

    1. 1

      The contribution-margin trigger is an interesting addition. Do you actually calculate this every billing cycle, or is it something you would use once a client starts consistently drifting from the original baseline?

  77. 1

    Curious how long it took before you saw the first real results?

    1. 1

      The first useful signals came from conversations rather than sales, so I'm still separating problem validation from willingness to pay.

  78. 1

    Curious how long it took before you saw the first real results?

  79. 1

    Curious how long it took before you saw the first real results?

  80. 1

    Curious how long it took before you saw the first real results?