How to Validate a SaaS Product With Your First Customer

Every founder I know has a prototype sitting somewhere. It works on their laptop. It works in the demo. Nobody is paying for it, and nobody has tried to break it.

We had one too. At ITMTB we'd been building a search engine for enterprise catalogues for a while. We already ran the website for one of our customers, and that's how their need came up. Their search was failing, and we had a search engine. So we deployed it for them first. Turns out that's the best way to validate a SaaS product: with your first customer, before strangers get to it. Here's how it went for us, and what they taught us before we let anyone else sign up.

The engine was ours long before they needed it. They just became its first real test.

Why deploy for one customer before opening sign-up?

Because a prototype tells you nothing about the real world. A customer tells you everything, usually on a Monday morning.

The customer was The Business Research Company, a market research publisher. Their visitors searched for reports and often found nothing. In a sampled week, 53.4% of searches came back empty. We hand-checked 500 of the failures; 470 were for a report they already had.

People were walking into a shop that had exactly what they wanted, and the shop was telling them no.

That's a perfect first customer. The pain is real, you can measure it, and they'll forgive a rough edge if the numbers move.

What did the first customer prove?

That the engine works on a real catalogue, with real visitors.

In its first days live on their site, zero-result searches fell to 5.1% of search intents. The two numbers aren't measured the same way (searches before, search intents after), and the case study explains both. Even with that caveat, that's not luck.

The number wasn't the most useful thing they gave us. Their team tested it with their own queries and the ones their buyers had typed, and every complaint became a test before it was fixed. That kind of feedback is hard to get. A first customer gives it because they want it to work as badly as you do.

(How the engine itself was built is in the engineering write-up.)

What does one customer let you get away with?

A lot more than you think. I found that out when I started opening the product up.

One customer lives in a protected house. Their own systems stand in front of yours. The people running it know each other by name. When a question comes up about limits, someone picks up the phone.

None of that is wrong. That's what deploying for one customer looks like.

A self-serve product has no house. Anyone on the internet can walk up to it, at 2 a.m., while your team is asleep. The first visitor could be a customer, a competitor or a bot.

That was the first lesson, and it shaped everything after it.

A single customer trusts you. A product has to trust nobody.

The features barely changed. What changed was who we could trust. With one customer, their setup quietly answered who could call it, who was an admin and whose data was whose. Now the product has to answer that on its own.

How do you keep one customer's data away from another's?

Never let the visitor decide.

With one customer, "whose data is this?" never comes up. In a product it's the most important question, and the visitor must never answer it. The product works out who a request belongs to on its own side, and nothing the visitor sends changes that.

Better still, leave no place in a request where a stranger could even ask for someone else's data. A question that can't be asked can't be answered wrongly.

One more. Whatever a customer uploads ends up on their visitors' screens. Treat it like a parcel from a stranger.

Where should limits and the free plan live?

Decide where limits live before you sell the first plan.

With one customer, a limit is a line in an email and a polite call when it's crossed. In a product there's no call. The system decides, for every customer, at every hour.

We run more than one software on Tomorrow Central, so limits live in one shared place every software reads, not inside Search. Otherwise each software invents its own plans and none of them agree.

Two rules I'd give any founder:

• Decide what happens when a limit runs out, not only what the limit is. A search failing on your customer's website hurts more than an upload refused in a dashboard.
• If the system can't tell whether someone is within their limit, it says no. Being generous by mistake is the expensive kind of generous.

We tied our free plan to a verified website, not just an email address. Emails cost nothing to create. Websites cost something, and each belongs to someone. Anchor your free tier to something expensive to multiply, or your free tier will be multiplied for you.

Should the first customer and the product share one codebase?

My first instinct was to split them. Keep the customer's version safe, build the product separately, merge when convenient.

Our first plan said exactly that. We threw it out.

The first customer is the best source of feedback the product will ever have. If the two versions drift apart, every fix has to be carried across by hand, and one day one of them stops getting fixes. Usually it's the one that pays you.

So we kept one codebase, and we release it twice. The customer's deployment and the product run the same engine, and they never share data, traffic or servers.

One codebase, so the first customer keeps getting every fix.

That only works with some discipline:

• Anything new the product needs stays off unless it's switched on, so the first customer's behaviour is always the default.
• Every change has to prove it leaves the first customer exactly as they were, measured against their own search results. If their numbers move, the change waits.

What does the dashboard have to do once you're not in the room?

Tell people what went wrong.

Our first customer had us. Their console showed every search, every failure and every click.

A self-serve customer gets a sign-up form and a blank screen. So the product has to do the explaining. If an upload has bad rows, say which ones and why. If searches are finding nothing, show the searches. If you leave people guessing, they'll decide the product is broken, and they won't write in to tell you.

The rule I use now is simple. Anything I'd explain on a call, the dashboard has to explain on its own.

Where is it now?

Self-serve. Search is open on Tomorrow Central and runs the same engine our first customer still uses. Search didn't build its own sign-in or user management. It borrows them from the platform, like every other software there.

The prototype came first. The product is everything the customer taught us.

Key takeaways

• Find one customer whose problem you can measure, and let them be the first to break your product.
• Plan for strangers before you open the doors, even while that friendly customer is your only user.
• Keep the first customer on the same code as everyone else, and protect their results every time you ship.

Frequently asked questions

How do you validate a SaaS product with your first customer?

Deploy it for one customer with a measurable problem. Measure before and after, turn their complaints into tests, and open sign-up only when the product can work without your team in the room.

What makes a good first customer for a new product?

Pain you can measure, and a team willing to test with their own data and tell you what broke. They should want the problem fixed more than they want polish.

Should the first customer get a separate version of the product?

I wouldn't. Keep one codebase and release it twice, so they get every fix. Make every change prove it leaves them untouched.

How do you stop people abusing a free plan?

Tie it to something that's costly to multiply. We use a verified website, not just an email address, because anyone can make a hundred email addresses before lunch.

What changes when a product goes from one customer to self-serve?

Trust. One customer lets you lean on their surroundings and your team. A self-serve product has to protect every customer and explain itself.

Try it, or talk to us

Search is open on Tomorrow Central, with a free plan. Sign up here, upload your catalogue or import it from your website, and try it with your worst typos.

If your catalogue needs the tuning and testing our first customer got, that's the work we do at ITMTB. See enterprise search at ITMTB.

And if you've got a prototype gathering dust, find the one customer who needs it badly. They'll teach you more in a month than the prototype did in a year.