# Should You Take a Customer Deposit Before Building?

> Decide when an upfront customer deposit is useful evidence and working capital, and when it creates refund, delivery, or trust risk you are not ready to carry.

By buildpurdue Team · September 17, 2026 · 8 min read

Source: https://www.buildpurdue.org/blog/customer-deposit-before-building

---

Take a customer deposit before building only when you can describe what the customer is reserving, what you will deliver, and what happens if either side stops. A deposit can test whether a buyer will make a real commitment and help fund work with upfront costs. It can also create a refund obligation, delivery pressure, and a trust problem if you collect money before you understand the job.

The useful question is not “Can I get someone to pay early?” It is: **“What uncertainty does this deposit reduce, and can I honor the promise behind it?”**

## Key takeaways

- Use a deposit to reserve a defined piece of work, capacity, inventory, or a dated next step—not to disguise an unbuilt idea as a finished product.
- Keep the amount tied to the costs and commitment you can explain, with a clear balance, timeline, cancellation rule, and refund rule.
- Treat payment as stronger evidence than a compliment, but not as proof that the product will work or that the customer will renew.
- Keep deposits separate from revenue, cash available to spend, and a signed promise to deliver until the terms and accounting are clear.

## What is the customer actually paying for?

Start by naming the thing the deposit reserves. It might secure a place in a limited implementation window, fund materials for a custom order, or start a short discovery-and-build engagement. It should not be a vague payment toward “the product” when you cannot say what the first customer will receive.

Imagine a founder building scheduling software for independent music teachers. One studio wants a version that imports its existing calendar and sends reminders. The founder could ask for a $500 deposit, but that number means little until the offer says what the $500 reserves: a four-week implementation slot, one import, two setup calls, and a defined review date. The remaining balance and the conditions for continuing belong in the same written offer.

This is different from a [paid startup pilot](/blog/charge-startup-pilot). A pilot is a bounded test of a customer outcome. A deposit is a payment structure inside an offer. You can use both, but neither removes the need to define the outcome, scope, and decision at the end.

## Use the deposit to test a real commitment

A deposit is useful evidence because it asks the customer to give up money, not only attention. But the signal is still narrower than “the business works.” The payment may show that one buyer values a specific promise enough to reserve capacity. It does not prove that the buyer will use the result, that other buyers want the same thing, or that delivery will be profitable.

Before asking for money, write down the evidence you want:

1. **Buyer:** Who is paying, and do they control the budget or need another approval?
2. **Problem:** What urgent workflow or cost is the offer addressing?
3. **Deliverable:** What will exist at the end of the first phase?
4. **Decision date:** When will both sides decide to continue, change scope, or stop?
5. **Next commitment:** What does the customer do besides pay—provide data, attend setup, test the result, or schedule the review?

If the customer cannot agree to the problem, deliverable, or next step, a deposit is probably premature. Ask for a research conversation or a scheduled evaluation instead. Payment should make an existing commercial conversation more concrete, not substitute for one.

## Make the risk-sharing terms plain

An upfront payment changes who carries risk. The customer gives you cash before delivery; you take on the obligation to do what the offer describes. [Stripe's guide to advance payments](https://stripe.com/resources/more/advance-payments) describes partial payments, deposits, milestone payments, and retainers as different structures with different delivery and contract implications. Pick the smallest structure that matches the work.

Your written terms should answer:

| Question | What to state |
| --- | --- |
| What is due now? | The exact deposit amount and what it reserves. |
| What comes next? | The remaining balance, milestone payments, or the condition for a later charge. |
| When do you start? | A date or a start window that depends on receiving the deposit and required customer inputs. |
| What can change? | The assumptions that would require a revised scope or price. |
| What if someone stops? | The cancellation, refund, credit, and rescheduling rules. |
| What counts as delivered? | The acceptance event or review that ends the first phase. |

Do not label a payment “nonrefundable” as a shortcut around a fair explanation. If you have already reserved scarce capacity or purchased an unrecoverable input, say what that cost is and when it becomes committed. A buyer should be able to understand what they are risking before they pay.

## Size it around your downside, not your excitement

The deposit should make the decision real without making the customer finance an open-ended experiment. A simple starting point is to cover the work you must commit before the next milestone, while leaving enough value and payment at the milestone that delivery still matters to both sides.

For the music-teacher example, the founder might need a week of data cleanup and setup before the customer can test the workflow. The deposit can cover that bounded effort. It should not fund six months of product development based on a promise that the studio might eventually use the software.

Model three cases before you ask:

- **On time:** the customer provides inputs, you deliver the first milestone, and the balance is paid as agreed.
- **Delayed:** the customer misses a dependency or the build takes longer; the terms say whether the start date moves or the customer can cancel.
- **Stopped:** the customer or founder ends the work; the agreement says what portion is earned, refundable, or converted into a credit.

Stripe's guidance on payment capture notes that charging before fulfillment can improve cash timing but can also increase refund and customer-experience risk when the final delivery is uncertain. [Its pre-order guidance](https://support.stripe.com/questions/accepting-payments-for-pre-orders?locale=en-GB) also recommends limiting orders, setting realistic expectations, and keeping enough cash to handle refunds or disputes.

That is the operational test: if one cancellation would create a crisis, the deposit is too large, the promise is too vague, or both.

## Do not spend the deposit twice

Money in the bank is not automatically money you have earned. [IRS Publication 538](https://www.irs.gov/publications/p538) explains that advance payments can have specific income-recognition treatment and that the correct timing depends on the business's accounting method and the type of payment. The founder does not need to solve that question by intuition.

Track the deposit separately from ordinary sales and mark what obligation it relates to. Ask a qualified accountant how the payment should be recorded, when it becomes revenue, and how refunds or credits should be handled. The same discipline helps with cash planning: keep enough aside for delivery costs, taxes, payment disputes, and any refunds promised in the terms.

The [SBA's cash-flow guidance](https://www.sba.gov/blog/2016/2016-09/how-net-30-accounts-help-conserve-business-cash-flow/) includes minimum deposits as one way a small business can improve the timing of cash received. That is a cash-management tool, not permission to treat customer money as free runway. Use it to fund a defined next step you can actually perform.

## When not to ask for one

Skip the deposit when:

- you cannot describe the first deliverable without saying “we will figure it out”;
- the customer is paying mainly to influence a roadmap rather than to receive a defined result;
- the work depends on approvals, data, or suppliers you have not confirmed;
- the refund, cancellation, or accounting treatment is unclear; or
- you are using one buyer's payment to justify building a broad product for a market you have not tested.

In those cases, use a smaller commitment. Schedule the evaluation, ask for access to the right users, run a manual test, or write a short design-partner agreement. A customer who will not pay a deposit may still give valuable evidence; a customer who does pay may still expose a bad assumption.

## FAQ

### Is a customer deposit proof of demand?

It is stronger evidence than an expression of interest because the buyer has accepted financial risk. It is not proof of repeatable demand, successful delivery, or renewal. Keep it in a separate evidence category from revenue that has been earned and customers who have reached the promised outcome.

### Should the deposit be refundable?

Sometimes. Make the rule fit the work and state the conditions in plain language. If you have not started and have not incurred an agreed nonrecoverable cost, a refund may be the cleanest way to protect trust. If the deposit reserves scarce work or pays for a defined first milestone, the agreement can explain what is earned and what is returned if the project stops.

### How much should a startup request upfront?

There is no universal percentage. Start with the cost and capacity you must commit before the next decision, then check whether the amount is small enough for the buyer to approve and large enough to make the decision real. Do not copy a standard 50% rule without understanding the work, buyer, and downside.

## Wrap up

Before asking for a deposit, write a one-page offer with one customer, one first deliverable, one start window, one decision date, and one cancellation rule. If you cannot make those five things clear, you are still selling an idea. If you can, the deposit can fund a bounded test while showing whether the buyer is willing to share the risk.

If you want peers to pressure-test the offer before you send it, bring the scope, terms, and downside case to the [buildpurdue cohort](/cohort).