Set a cost limit for a free proof of concept

A free proof of concept can become an open-ended delivery project if nobody agrees what the customer needs to learn. Before assigning engineers, write down the buying decision, the technical uncertainty and the evidence that would resolve it. A request to explore possibilities gives finance little basis for deciding how much work to fund.

Ask the prospect to name a decision-maker and explain what happens after the test succeeds. Confirm whether budget approval, security review, procurement and a competing evaluation still remain. Technical success may be necessary for a purchase without making that purchase likely or imminent. The commercial forecast should reflect the remaining steps.

Set an end date and specify the customer inputs required before work begins. If representative data or access is missing, keep the evaluation unstarted or revise its scope. Engineering time spent waiting for permission still consumes a calendar slot that could support another customer.

Estimate preparation, configuration, customer meetings, troubleshooting, documentation and the final decision review. Include the people who approve security exceptions or build temporary integrations. A proposal describing two days of setup can omit several weeks of scattered interruptions to specialists whose calendars are already full.

Separate incremental spending from staff capacity. Existing salaries may be committed for the month, while cloud resources, contractors and travel create new cash costs. Staff time still has a decision cost when the evaluation delays product work or another qualified deal. State which alternative assignment is affected and ask its owner to assess the consequence.

Use a named work plan rather than multiplying every attendee by the entire project duration. A security reviewer needed for an hour should not be costed as a full-time participant. Conversely, a developer who must remain on call should not disappear from the estimate because only a few calls are expected.

In an illustrative evaluation, an engineer needs 30 hours, a solution architect needs 10 hours and a project coordinator needs five. Assume internal planning costs of $90, $140 and $50 per hour respectively. The modeled staff cost is $4,350. Add $650 for temporary computing and the evaluation uses $5,000 of modeled resources.

Suppose the proposed first-year contract would produce $24,000 of contribution after the delivery costs included in the company's chosen definition. At a 25% chance of winning, its probability-weighted contribution is $6,000. The apparent $1,000 excess over evaluation cost is narrow and sensitive to both assumptions. This example is a decision calculation, not a market benchmark or a recommended universal threshold.

Document what the contribution figure excludes, including further selling costs or shared overhead. Also identify whether $24,000 arrives during the first year or depends on renewal. Comparing an immediate evaluation cost with several years of uncertain contribution can make a weak opportunity appear attractive.

Break the evaluation into stages only when each stage can resolve a meaningful question. A short data-compatibility check may show whether a longer integration trial is feasible. If it fails, the company can stop before committing the rest of the engineering budget. A sequence that merely relabels the same mandatory work provides no such choice.

For each stage, state the spending ceiling, required evidence and person authorized to approve the next stage. The sales owner should not be the only person deciding whether a technically difficult prospect receives another week of engineering. Include the delivery or product owner whose capacity would be used.

Customer participation can be an acceptance criterion. If the test requires a decision workshop or validated data, make those commitments explicit. Repeatedly missing the agreed inputs is information about the project's current readiness. It may justify rescheduling the evaluation even if the prospect remains commercially interesting.

New requirements often arrive after a useful demonstration. Classify each request: does it resolve the original uncertainty, change the proposed purchase or begin implementing the eventual solution? That distinction lets the team answer the customer without automatically absorbing work that belongs in a paid engagement.

If a request changes the test, show the additional hours, cash spending and displaced work before approval. Update the commercial assumptions too. A larger potential contract does not improve the calculation if the new feature adds even more delivery cost or extends the decision indefinitely. Keep accepted requests in a dated scope record so the final result can be evaluated against the actual agreement.

Agree ownership and permitted use of any temporary configuration, customer data and custom code with the appropriate commercial and technical reviewers. The budget should include cleanup and removal of temporary access. Ending the sales opportunity does not automatically end those operational responsibilities.

Record the technical result, customer response, actual resource use and the next commercial decision. If the customer declines, retain the stated reason without inventing a causal explanation. A lost deal may reflect budget, timing, procurement or product fit; the evaluation record should distinguish those outcomes.

Across completed evaluations, compare estimated and actual hours by work type. Look for repeated sources of underestimation, such as custom data preparation or specialist reviews. Use the findings to improve future scopes. Avoid judging the program only by signed contract value, because a large win can conceal costly unsuccessful work and demanding delivery obligations.

Finance can keep the internal decision model separate from the accounting treatment of costs. Financial statements organize expenses and cash flows under the applicable reporting basis; the evaluation model organizes resources around a purchase decision. Reconcile actual spending back to the books, then close temporary resources and access when the test ends.