How to Price Custom Software and Retainer Work Without Underselling
Updated
Before quoting custom software or a retainer, write down the problem, the work you can commit to and the assumptions behind the price. A competitor's rate card or a rough hours estimate can be a comparison point, but neither explains the scope of your particular engagement.
This is a proposed decision framework, not a report of client savings or a formula for a guaranteed return. Use records the client can check, and label estimates as estimates.
Choose a Pricing Model That Fits the Uncertainty
Hourly work can suit investigation when the scope is still unclear. A fixed project price can suit a defined deliverable with acceptance criteria. A retainer can suit recurring responsibilities with a named owner and review cycle. None is automatically the right choice: explain what is included, what changes the price and when the client can reconsider.
Do not turn an uncertain discovery task into an unconditional delivery promise. Consider a bounded diagnostic phase before committing to a larger implementation.
Describe the Problem Before Setting the Number
Ask the client to show the current workflow. Record the steps, people involved, available time records and existing tool costs. If someone estimates time spent on manual entry, keep the estimate separate from measured time. Do not treat all time potentially saved as cash that will necessarily be recovered.
Compare a targeted correction, a standard tool and custom work against the same requirements. Include maintenance, training and the effort needed from the client's team. Leaving the current system in place should also be an explicit option to assess.
Make Retainer Responsibilities Visible
Describe the recurring work and how completion will be checked. Specify who supplies information, who approves changes and how unexpected work is handled. Business goals can guide priorities, but do not convert a desired ranking, lead count or commercial result into a promise you cannot substantiate.
| Pricing input | What to document |
|---|---|
| Problem and scope | The workflow to improve and the agreed deliverable |
| Delivery cost | Implementation, review, support and third-party costs |
| Alternatives | Smaller changes, existing products and continued operation |
| Uncertainty | Assumptions to test and the point at which to revise the scope |
Agree on Change and Review Points
Keep exclusions and dependencies alongside the price. State whether a new integration, additional user group or change in approval requirements needs a separate estimate. For ongoing work, set a review date and use it to compare the agreed responsibilities with what the business now needs.
If a price needs to change, explain the scope or cost change and offer a concrete choice about future work. Do not present an unmeasured improvement as proof that a higher fee has already paid for itself.
Start With a Bounded Diagnostic
Schkovl's Digital Growth service describes a Gap Analysis before ongoing marketing. Our guide to what a Gap Analysis is explains that diagnostic starting point. Use it to define the problem and an appropriate scope before selecting a pricing model.