Validate a SaaS idea with prepayment

Shops liking an idea is pleasant and almost useless as evidence. Before two months of coding, you want a signal that costs the customer something they'd hate to lose.

Reactions from a shop owner fall on a scale, from weakest to strongest:

1. A compliment: "Great idea, I love it!" Costs nothing.
2. A vague promise: "Call me when it's ready." Costs nothing today; often a polite "not now".
3. Time: he books an hour for a follow-up with his administrator. Now he's giving up something real.
4. Data: he sends his client list so it can be loaded at launch. That takes effort and trust.
5. Money: he prepays for something that starts later.

The rule is simple: the more a signal costs the customer, the more you can trust it. Compliments are given to be kind; money is given because the problem is worth solving.

This is why the strongest test of demand before building is a pre-sale: asking shops to pay now, openly, for a product that starts on a stated date, with a full refund if it doesn't.

By now GarageDesk knows the problem is real: shops already spend on regulars who forget their service. That doesn't yet prove the solution works. Solution validation checks whether the proposed way of working fits the customer's day and beats what they do now.

The method is to walk each owner through a normal week with the product: who types what, at what moment, when a reminder goes out, what the car owner sees. Show the demo, but ask where it would break.

Good solution questions are concrete and about their routine:

• "In a normal week, who would type in the mileage, and at what moment?"
• "What happens when a regular changes his phone number?"
• "Would this replace the niece's notebook or run beside it?"

Questions that don't validate the solution:

• "What took the most time last week?" checks the problem, which you've already done;
• "Wouldn't automatic reminders be great?" is leading;
• "How much would you pay?" invites a guess instead of a commitment.

Every awkward question an owner asks now, like Dennis's "who types in the mileage?", is cheaper to answer before launch than after.

A pre-sale asks for money now for something that starts later. It's honest when the customer knows exactly what they're paying for. The offer page needs four things:

1. The price: for GarageDesk, 1,800 UAH for three months or 6,000 UAH for a year.
2. What the shop gets: automatic service reminders to its regulars, in plain words.
3. The start date: March.
4. The refund terms: all the money back if GarageDesk isn't live by 1 April.

The refund date caps the risk on both sides: a guarantee for the shop and a deadline for the founders.

Just as important is what stays off the page:

• invented social proof, like "37 shops have already joined" when none have;
• features you won't build soon, like online booking and repair history, added "to make the offer bigger".

Both would make every prepayment evidence of a false promise rather than of a real problem. They can also mislead customers in ways that consumer and advertising rules may treat as unfair practice. A pre-sale is only a test if the offer is true.

A pre-sale with a refund date creates a promise: if the product isn't live by that date, every prepayment goes back in full. Until the date passes and the product is delivered, treat the money as not yet yours.

In practice that means knowing one number at all times:

money held for refunds = sum of every prepayment taken

Example: by the end of January, two shops prepay three months (2 × 1,800 = 3,600 UAH) and two prepay a year (2 × 6,000 = 12,000 UAH). Together: 3,600 + 12,000 = 15,600 UAH that must stay untouched until 1 April.

Spending it on anything you couldn't take back, such as a laptop, an ad campaign or a contractor, turns a test into a debt. If the launch slips, the refunds would come out of the founders' personal savings, and the "no arguing" refund promise becomes hard to keep.

Keeping prepayments separate, even just in a separate account, makes the promise easy to honor and the result easy to read: the money in it is exactly what shops committed.

Note that this is about the founders' discipline; how prepayments are treated for tax depends on the business's tax status and is a question for an accountant.

A fake door test puts something on a page that doesn't exist yet, a button, a plan or a feature, and counts how many people click. Nobody pays; after the click, people see a "coming soon" note.

A pre-sale is a cousin with one decisive difference: it takes real money, openly, with a start date and a refund date.

What each one tells you:

• clicks show curiosity: someone wanted to know more, at no cost to them;
• money shows the problem is real: someone valued the result enough to pay before seeing it work.

A fake door can be useful early, to see whether anyone notices an offer at all, and it's cheap to run. But for the question GarageDesk faces, "will shops pay for reminders before Nina spends two months coding?", curiosity is not enough evidence.

A fake door also needs care: if people think they're buying and then find nothing, it feels like a trick. A pre-sale avoids that because the terms are on the page from the start.

Some of the warmest answers to a pre-sale are promises: "I'll definitely buy when it's ready", "call me when it's ready", "put me down for one". They feel like near-sales. They aren't.

A promise about the future costs nothing today. The owner may mean it, but he may also be ending the conversation kindly, waiting to see whether others go first, or simply forgetting by March. Nothing in the promise lets you tell those apart.

So record each answer as exactly what it is:

• prepaid: money received, with the plan chosen;
• not now: "call me when it's ready", "I'll definitely buy later", "send me the details";
• no: a clear refusal, ideally with the reason.

Don't create a "maybe-yes" column. It fills up quickly and makes the result look far better than it is.

"Not now" answers are still useful: they're the first list to call at launch, and the reasons behind them can point to something the offer is missing. They just don't count toward the rule for building.

When a shop wants to pay but asks for a discount first, the instinct is to give a little off the monthly price to close the deal. That's usually the wrong lever.

A discount on the monthly price:

• lowers revenue from this shop every month, for as long as it stays;
• tells every shop that the price is negotiable, so the next one asks too;
• is hard to undo later, because raising a price means a hard conversation.

The better move is to keep the monthly price and point to the yearly option, where the discount already lives: 6,000 UAH for a year instead of 12 × 600 = 7,200 UAH. The shop gets a lower effective price, and in exchange GarageDesk gets a year of commitment and the money up front.

So the conversation goes: "The monthly price stays 600. If you'd like to pay less, the yearly plan works out cheaper: 6,000 for twelve months."

The next lesson works through why the yearly plan is on the page at all and what it does to the numbers.

The same discipline that worked for choosing the problem applies to the pre-sale: write the rule for building before the first ask. A number, a sample and a date.

GarageDesk's rule: "We build if at least 3 of the 12 shops prepay by the end of January." If fewer prepay, the founders go back to the problem, not to the code.

A good rule has three parts:

• a count of real commitments: prepayments, not likes or promises;
• a fixed sample: the 12 shops Oscar will ask, so the share means something;
• a deadline: the end of January, so the test can't drift for months.

Weak rules fail in predictable ways:

• "We build if shops like the offer": liking can't be counted, and every shop likes something;
• "We decide once we see the results": the line moves to wherever the results land;
• "We build anyway; the pre-sale is just for cash": then it isn't a test, and a weak result changes nothing.

With the rule written, the outcome is a decision, not a debate.