Does the next AI customer fit your development plan?

A new customer wants to start next month. The AI demonstration works, the commercial terms are attractive, and the team can probably deliver by helping manually where necessary. One question remains: who will improve the product while those same people are serving the additional customer?

As the founder of aiomics, I find this a useful question about growth. It also applies to an internal AI team preparing to serve another business unit. Accepting work commits people’s future time. An admission decision should therefore make the effect on the next product improvement visible.

A warning worth making operational

In a Y Combinator video published on 3 June 2026, Charlie Warren warns that too many early pilot customers can absorb the capacity needed to build the product. His account prompted this guide. It is practitioner advice, without a comparative study establishing an optimum customer count. [1]

Google’s engineering chapter by Vivek Rau distinguishes repetitive operational work from work that durably improves a service. It describes protecting engineering time. This concerns software operations; transferring the idea to an AI service requires judgment about the actual work. [2]

The proposal below is my own planning exercise. It tests whether one additional commitment fits the team’s next improvement cycle. It supplies neither a universal staffing ratio nor evidence that a particular AI business will become profitable.

Put the next improvement in the calendar

Consider a fictional team preparing order-status reports for business customers with AI assistance. It has 80 staff-hours available each week after meetings, administration and other fixed commitments. Within this example, the two team members can undertake all the work described.

Existing delivery requires 40 hours. The team has reserved 24 hours for building and testing a better import function, and 16 hours for uncertain delivery effort. The total is 80. A prospective customer adds an estimated 12 hours of recurring weekly delivery and 16 hours of onboarding in the first week.

In that first week, planned work reaches 92 hours even before preserving any reserve: 40 + 24 + 12 + 16. Keeping the reserve raises the requirement to 108. The following weeks require 76 hours before the reserve, assuming the estimates hold. Only four hours remain for uncertainty, compared with the 16 previously reserved. The initial overload becomes a continuing reduction in the buffer.

This is an invented calendar calculation, not a measured productivity result. Hours are not freely interchangeable in real teams: specialist availability, dependencies and deadlines also matter. The exercise deliberately exposes a specific choice. Someone must change the start date, scope, staffing or improvement schedule. Unrecorded overtime would hide that choice.

Name what would be postponed

The import improvement needs an owner, an expected delivery date and a test. In this example, the hypothesis is that it will reduce repeated reformatting of incoming files while preserving completeness. Until tested, the time saving remains an assumption. It should not be spent in advance to justify accepting more work.

A new customer might make postponement worthwhile. Perhaps the contract pays for qualified additional capacity, or the customer provides cases needed to test the intended product. The decision brief should name the benefit and the improvement being deferred, together with a revised date. Calling every interruption “learning” leaves the expected learning unspecified.

I would separate three questions in the discussion: what must be delivered under the agreement, what is still unknown about the customer’s cases, and which reusable change the team intends to finish. For the unknowns, set a limited investigation period and identify the decision that its findings will change.

Check whether the improvement survives a new customer

Before expanding again, examine the import function against a retained set of representative cases, including troublesome file formats. Then assess a separate set from the new customer. Keep the acceptance criteria and the definition of human effort consistent. Record missing information, corrections and unresolved cases alongside time spent.

If only the original customer’s files become easier, the change still has value. The claim about reusability remains narrower. If results improve because a specialist silently repairs every difficult file, that effort belongs in the record. Required professional judgment and quality checks also remain part of delivery; describing work as repetitive creates no permission to remove them.

This is a proposed local comparison. It does not isolate causality when model versions, staffing and case mix change together. Record those changes and qualify the conclusion accordingly. A shorter processing time is useful only within the agreed quality and completion requirements.

A one-page decision before saying yes

For the next prospective customer or internal department, I would record the proposed start date, recurring delivery effort, onboarding effort, required skills and uncertainty reserve. Alongside them belong the next product improvement, its assigned time and the evidence needed to accept it as finished.

Then write the consequence of accepting the work: which commitment moves, which additional capacity is available, or which part of the request is reduced? Identify who can make that change and when the estimates will be checked against actual work. A later start or a smaller first assignment can be a concrete offer when immediate full delivery does not fit.

For leaders in pharmaceutical companies, medical technology and other service businesses, the same exercise can clarify an internal expansion. The decision concerns both the service promised today and the improvement that will make the next delivery more manageable. Putting both in the calendar makes the trade-off discussable before the promise is made.