Commercial clarity before the contract

The situation

Custom software starts with uncertainty. A third-party API may not provide the expected data. A seemingly small field may require new calculations and workflows. When a proposal hides these questions inside a single figure, both sides pay later: the customer encounters an unexpected request for funds and the team absorbs work it had not priced. Neither reaction is a good foundation for trust.

The decision I made

I began putting visual mind maps and risk matrices into proposals. They helped people see the proposed scope, dependencies and known unknowns—particularly integrations—without first learning how to read a technical specification. I replaced false precision with a realistic range of time and cost. Where the shape of the work warranted it, I discussed time-and-materials billing with a lower and upper indicative project range rather than pretending we could know the final effort before discovery.

The hard conversation

When new requirements appeared, I tried to make the choice explicit: fund the work now, move it to a later release, or shape it as Phase 2. That does not mean every change was optional or comfortable. It does mean we could ask whether it served the customer’s goal, what it would cost, and what it displaced. I would rather describe the implications while a choice remains than frame a change request as a surprise bill.

What changed

This approach reduced unplanned absorption and revenue leakage, improved predictability and made scope conversations more constructive. Customers had more flexibility over when to invest; the team had clearer commercial boundaries.

What stayed with me

Good commercial discipline is not the opposite of customer advocacy. The honest range, visible risk and explicit trade-off are often how we protect both.

The sale I didn’t make