A customer sees the purchasing app your team built and asks what it would cost to use it. The demo went well. Then they mention one small change. Purchases at their company need three approvals. Yours need two.

Before you quote the deal, ask who will make that change, who will test it on every release, and what happens when customer number three wants a different approval threshold. The first sale tells you somebody values the software. The second customer tells you how much work it takes to sell it again.

Run the second customer test

Pick a plausible second customer whose business works a little differently from yours. Give yourself an hour and walk their account through three ordinary moments. Write down who does the work each time.

  1. They sign up. Who sets up their account, appoints their first administrator, and invites the right people? Use two test companies and verify that a user at one cannot see the other’s invoices through a search, export, or shared link.
  2. They change a rule. Can an authorized administrator add that third approval, choose when it applies, and see who changed it? If your team has to deploy a separate version, put its testing and support costs into the price you quote.
  3. They call for help. An invoice export is missing. Can support see what happened and help the customer without getting access to unrelated records? Try the exercise with someone who didn’t build the app. Watch for the point where they have to call the one person who knows how it works.

Price the work that repeats

After the walkthrough, mark each step as something the customer can handle, something your team can handle through a documented process, or something that needs a developer. Give each manual step an owner and a rough time estimate. Separate the work you do once per customer from the work you do every time they change a rule or you release an update.

It’s reasonable to set up early customers by hand. What matters is knowing where that labor sits. A one-time setup can be part of the deal. A custom version that needs its own release testing keeps costing you after the contract is signed.

Jeffery Williams traces that lesson back to his time at Broadvox. A white-label telecom customer could have a simple experience because the platform did the hard work underneath: provisioning accounts, managing access, and applying billing rules. For your own product, start by asking which of those jobs your employees quietly do today.

Before the next sales call, write down one difference you’ll support through configuration, one service you’ll price into the deal, and one custom request you’re willing to decline. That gives you a clearer picture of what the next fifty customers would actually buy.