# Should You Set a Minimum Contract Size for Early Customers?

> Set a minimum contract size when small deals consume the same onboarding and support capacity as larger ones, then make exceptions only when the learning is worth the cost.

By buildpurdue Team · October 2, 2026 · 7 min read

Source: https://www.buildpurdue.org/blog/minimum-contract-size

---

Set a minimum contract size when the smallest deals are expensive to deliver, support, or customize relative to what they pay. Do not set one just because a larger number sounds more serious.

The useful question is not “What is the biggest customer I can win?” It is: **“What is the smallest deal that can pay for the work this customer will actually require?”**

Imagine Maya sells workflow software with a hands-on setup. A two-person customer and a 30-person customer both need a data import, training call, custom permissions, and weekly troubleshooting. If Maya charges them nearly the same amount, the smaller customer is not a smaller deal. It is a worse use of the same scarce capacity.

## What problem is the floor supposed to solve?

A minimum contract size is an operating rule. It filters opportunities whose revenue does not justify the delivery, support, risk, or opportunity cost they create.

Early founders still need to qualify customers instead of treating every signed deal as equally valuable. Stripe's guide to finding first customers describes qualification partly in terms of who is profitable to service and least difficult to support, not only who is easiest to close. [That is a better starting point than a revenue-only leaderboard.](https://stripe.com/guides/atlas/starting-sales)

List the work that happens before and after the signature:

- onboarding and data migration;
- training and implementation calls;
- custom configuration or integration;
- routine support and incident handling;
- contract, security, or procurement review; and
- the founder's time that could have gone to a more repeatable customer.

The floor should respond to that work. If the deal needs none of it, a low-touch price may be fine. If every deal needs it, the contract needs enough room to carry it.

## Calculate the work before choosing the number

Start with one recent customer rather than a market benchmark. Write down the hours your team spent getting the account from signed contract to a useful result. Separate one-time work from recurring work.

| Work | One-time hours | Monthly hours | What to check |
| --- | ---: | ---: | --- |
| Setup and data import |  |  | Can the customer do any of it? |
| Training and handoff |  |  | Is the same session reusable? |
| Support and review |  |  | Which requests are normal? |
| Custom work |  |  | Is it product work or consulting? |
| Contract and risk review |  |  | Does the buyer require extra coverage? |

Then estimate the minimum price that makes the account worth accepting. Include the cash cost of outside help, the value of internal time, and a buffer for work you cannot yet predict. This is an internal decision tool, not a promise that every customer will produce a particular margin.

Do not hide implementation in a vague “platform fee.” If setup is real work, show it as an onboarding fee, include it in the contract value, or narrow the implementation promise. Clear terms also make negotiation safer. AWS's startup contract guidance lists payment terms, acceptance criteria, data responsibilities, insurance, liability, and service levels among the issues that can change the actual burden of an enterprise deal. [A larger contract can therefore create more obligations, not just more revenue.](https://aws.amazon.com/blogs/startups/contract-and-legal-traps-to-avoid-startup-founder-sales-series-part-11/)

## Choose a floor that protects capacity, not ego

There are three reasonable ways to express the rule:

1. a minimum annual or monthly spend;
2. a paid implementation fee plus a smaller recurring subscription; or
3. a defined package with a fixed scope and a price below which you do not customize it.

Pick the form that matches the source of the burden. A large one-time migration may call for an implementation fee. Ongoing support may call for a recurring minimum. A deal that requires custom engineering may need a separate project agreement or a polite no.

The floor should be explainable in one sentence: “Our minimum covers the setup, support window, and service level included in this package.” That gives the buyer a boundary to respond to. It is better than saying the company only works with “serious” customers.

Keep the rule narrow enough to learn. Stripe notes that early sales should be done one customer at a time, with founders using the process to improve their understanding of the market. YC makes a related case for manually doing early work because the process teaches founders what customers actually need. [A floor should help you qualify that learning, not stop you from learning entirely.](https://stripe.com/guides/atlas/starting-sales) [Manual work can be useful when it is a deliberate learning loop rather than an unbounded promise.](https://www.ycombinator.com/library/96-do-things-that-don-t-scale)

## When should you make an exception?

An exception is reasonable when the smaller deal buys unusually valuable evidence, access, or a repeatable reference. But name the value before discounting. “This customer seems promising” is not a decision rule.

Write the exception into a small table:

| Question | Accept the exception when… |
| --- | --- |
| Learning | The account tests a decision you need to make soon. |
| Repeatability | The requested workflow could serve similar customers. |
| Access | The buyer gives you a credible path to a defined next conversation. |
| Capacity | You can deliver it without breaking existing commitments. |
| Exit | You know what happens if the learning does not materialize. |

The last row matters. A low-price customer should not receive an open-ended promise that the company will keep customizing forever. Set a review date, a scope limit, or a conversion condition before the work starts.

Do not use a strategic-logo story to excuse an account that consumes the team. A famous customer can still demand a custom integration, long payment terms, special security work, or an SLA you cannot measure. If the exception creates a new operating model, price that model separately or decline the deal.

## Test the floor before making it permanent

Run the rule against the last five opportunities you seriously considered. For each one, record the proposed value, estimated hours, support burden, contract requirements, learning value, and final decision.

Then use the floor for the next five qualified opportunities. Watch three outcomes:

- how many opportunities disappear before a proposal;
- whether the remaining deals require less unpriced work; and
- whether customers reject the number because the value is unclear or because the scope is too broad.

If every qualified buyer rejects the floor, the problem may be positioning, packaging, or a cost structure that does not fit the market. If buyers accept it but delivery still overwhelms the team, the floor is too low or the promise is too wide. If the floor blocks the exact customers who teach you the most, create a named learning exception with a budget instead of abandoning the rule.

## FAQ

### Is a minimum contract size the same as raising prices?

No. A price increase changes what a defined offer costs. A minimum contract size decides which opportunities are worth the company's delivery and support capacity. You can keep a low listed price and still require a paid setup or minimum monthly commitment.

### Should every early startup have a minimum?

No. If customers can onboard themselves and support is genuinely light, a minimum may add unnecessary friction. Use one when deal size and delivery burden have stopped moving together.

### What if a customer asks for a smaller pilot?

Make the pilot smaller in scope, not merely cheaper. Define the workflow, time limit, success evidence, support boundary, and conversion decision. A bounded pilot can be useful; an underpriced version of the full contract usually is not.

## Wrap up

Pull the last five opportunities into a table. Add every hour, obligation, and exception you would have to absorb. Set the smallest contract that covers the work you are actually promising, then reserve a separate budget for learning exceptions.

If you want peers to pressure-test the floor, scope, and exception rule, bring the decision to the [buildpurdue cohort](/cohort).