There is a particular kind of optimism that appears when a software engineer discovers a business idea. It usually begins with a small frustration, something the engineer has personally experienced and believes could be solved with a few hundred lines of code. The frustration becomes a feature, the feature becomes an application, and the application gradually becomes a company. By the time the founder begins seriously thinking about customers, several months may have passed, thousands of dollars may have been spent, and the product may contain features that nobody has ever requested. The engineer has solved the technical problem, but the business problem remains untouched.
The strange thing is that this sequence feels perfectly reasonable. If you want to open a restaurant, you need a kitchen. If you want to manufacture furniture, you need equipment. And if you want to start a software company, surely you need software. Yet this logic contains a dangerous assumption: that the difficult part of creating a business is producing the thing being sold. In many technology markets, production is not the primary obstacle. The real obstacle is discovering whether enough people experience the problem intensely enough to change their behavior and spend money solving it.
In 2010, a software developer named Joel Gascoigne confronted this distinction while considering a product that would eventually become Buffer. Gascoigne wanted a simpler way to schedule posts on Twitter throughout the day. At the time, sharing content consistently required more manual attention than he wanted to give it. The technical solution was not particularly mysterious. He could build a system that stored posts and published them according to a schedule. The more interesting question was whether anyone else cared about this inconvenience enough to use such a system.
Gascoigne had already experienced the consequences of building products without sufficient validation. In his later reflections, he described losing roughly a year and a half pursuing ideas before properly establishing demand. Rather than repeat that experience, he decided to conduct an experiment that would have seemed almost absurd to a founder obsessed with shipping software. He would try to acquire evidence of customer demand before creating the product itself.
The Product That Didn't Exist
Imagine visiting a website advertising a new application. The page explains a simple benefit, describes the problem being solved and invites you to learn more. You click because the problem sounds familiar, and the website asks for your email address so you can hear when the product becomes available. Nothing about this experience seems particularly unusual. Startups have used coming-soon pages for years, and most visitors understand that a product may still be under development.
What made Gascoigne's approach different was his attitude toward the people who responded. He was not primarily interested in accumulating an impressive waiting list that could later be shown to investors. He wanted to understand whether visitors had the problem he imagined, why they were interested and what they expected the product to accomplish. A signup was not the conclusion of the experiment. It was the beginning of a conversation.
This distinction matters because an email address is a remarkably ambiguous signal. Someone may sign up because the product sounds interesting, because the design looks attractive or because they are curious about what a founder is building. None of those motivations necessarily translates into a willingness to use the software regularly, much less pay for it. Gascoigne recognized that he needed to distinguish casual curiosity from meaningful demand, and the landing page gave him a way to begin making that distinction without investing months in development.
The initial experiment was deliberately small. Gascoigne described what the proposed product would do and watched whether people took the next step. When they did, he contacted them personally, often exchanging emails about their existing problems and sometimes speaking with them directly. The website created the initial contact, but the conversations supplied much of the useful information. Instead of guessing what customers might want, he was hearing from people who had already demonstrated enough interest to act.
The Pricing Page That Changed the Experiment
After discovering that some people were interested in the idea, Gascoigne introduced a more demanding test. He added pricing options to the website so visitors could indicate whether they would consider a paid version of the proposed service. This changed the meaning of the interaction. A person clicking a button to learn about a free product was expressing curiosity, while someone selecting a paid plan was revealing at least some willingness to exchange money for the promised benefit.
There was still no finished software behind the offer. Visitors who selected a plan were informed that the product was not ready and could leave their email address for updates. The important point is that the pricing decision occurred before the visitor reached that explanation. Gascoigne was observing what people did when the proposed solution carried an explicit financial cost, rather than merely asking whether they liked the concept.
This is a subtle but important difference in how founders conduct market research. When someone asks whether you would use a hypothetical product, agreeing is socially easy. You can encourage the founder without sacrificing anything. When you are asked to choose between a free plan and a paid plan, the decision begins to resemble a real purchase. It is still not equivalent to handing over a credit card, but it provides more information than a compliment.
The experiment was not evidence that every person clicking a paid plan would eventually become a customer. People can express willingness to pay and then change their minds when confronted with an actual transaction. What Gascoigne gained was a sequence of increasingly meaningful signals: people understood the proposition, some wanted to learn more, and some were interested enough to consider paying. Those signals reduced uncertainty sufficiently for him to proceed with a deliberately limited first version of the software.
The Difference Between Interest and Commitment
Consider a founder who wants to build software that automatically generates financial reports for small businesses. Before building anything, the founder interviews twenty business owners and asks whether automated financial reporting would be useful. Eighteen say yes. Several compliment the idea, and two ask to be notified when the product launches. The founder leaves convinced that the market has been validated.
But what exactly has been learned? The interviews establish that financial reporting is a recognizable activity and that business owners generally prefer less manual work. They do not establish how much time the problem consumes, whether existing tools already solve it adequately, who controls the purchasing decision or whether the benefit is worth a monthly subscription. The founder may have discovered a preference without discovering a business.
Now imagine a different experiment. The founder identifies ten companies currently preparing financial reports manually and offers to produce the next report for them using a combination of spreadsheets and manual work. The founder asks each company to pay a modest amount for the service. Perhaps only two agree, but those two provide something the original eighteen compliments did not: evidence that the problem is sufficiently important to justify spending money.
This is why customer commitment should be understood as a spectrum rather than a binary condition. Reading an article requires little commitment. Clicking a product link requires slightly more. Providing an email address requires more still. Scheduling a meeting, sharing business data, agreeing to a pilot and making a payment each represent increasingly meaningful investments. The further someone moves along that spectrum, the stronger the evidence that the problem matters to them.
Gascoigne's pricing experiment occupied an intermediate position on this spectrum. It did not prove that the business would succeed, but it created a more demanding test than asking strangers whether the idea sounded appealing. More importantly, it gave him specific people to contact and learn from, allowing the next decision to be informed by observed behavior rather than optimism alone.
The Seven Weeks That Followed
After the landing-page experiments, Gascoigne began building Buffer's first functional version. He focused on the essential job: allowing people to schedule posts without manually publishing each one. Features that might have made the application more impressive were postponed because they were not necessary to test the core value proposition. The first version launched on November 30, 2010, following a roughly seven-week development period.
The product was incomplete by the standards of a mature software company. Some features mentioned in early pricing materials had not yet been implemented, and Gascoigne later acknowledged that the initial version lacked capabilities that might ordinarily have seemed essential. But the application could perform its central job, and that was enough to begin learning from actual usage. Within days of launch, Buffer acquired its first paying customer.
The early numbers were modest. In a later account of the validation process, Gascoigne reported roughly 120 signups during the seven-week period and said that about 50 of those people began using the product when it launched. One became a paying customer three days after launch, followed by another several weeks later. These figures would hardly impress someone accustomed to reading about startups acquiring tens of thousands of users overnight, but they reveal something more important than rapid audience growth.
The founder had connected an observed problem to a proposed solution, tested interest before development, spoken with potential customers, built a limited product and obtained payment from someone who found it valuable. The entire sequence created evidence that could guide the next stage of the company. Instead of building additional features because they seemed interesting, Gascoigne could begin deciding what to build based on real customers and their behavior.
Why Founders Build Before They Validate
There is a psychological reason this approach remains difficult, especially for technical founders. Building software produces visible progress. Every completed feature creates a sense of accomplishment, every passing test confirms that something works, and every new interface makes the company feel more real. Customer discovery offers much less emotional certainty. You can spend an entire afternoon interviewing prospects and discover that your assumptions were wrong, leaving you with less confidence than you had when the day began.
This creates a powerful incentive to remain in the development environment. Code is relatively predictable. If a function is incorrect, you can inspect it, change it and run the test again. Customers are less accommodating. They misunderstand your pitch, contradict one another, ignore your emails and sometimes explain that the problem you have spent months trying to solve is not particularly important.
The uncomfortable truth is that customer validation threatens the founder's original idea. Building protects it. Every hour spent developing the product can be interpreted as progress toward the imagined future, while every conversation with a potential buyer risks revealing that the future is unlikely to arrive. The result is a strange inversion of rational behavior: founders often spend the most time on the activity they can control and postpone the activity that would tell them whether the business is worth pursuing.
Gascoigne's experiment reversed that incentive. By making the landing page the first deliverable, he made learning about demand the initial form of progress. He could still experience the satisfaction of shipping something, but the thing being shipped was an experiment rather than the final product. The website existed to expose the idea to reality, not to protect it from criticism.
How to Validate a SaaS Idea Before Building It
The first step in validating a SaaS idea is to describe the problem independently of the product. This sounds straightforward, but founders often struggle because they have already fallen in love with their proposed solution. Instead of saying that they are building an AI-powered customer-success platform, they should describe the underlying problem: customer-success teams at growing SaaS companies cannot reliably identify accounts at risk of cancellation before renewal conversations begin. The second description identifies a person, a situation and a potential consequence, which makes it possible to investigate whether the problem is real.
Next, find people who experience the situation and examine how they currently handle it. Ask what happened the last time the problem occurred, how much time or money it consumed, what alternatives they considered and whether anyone inside the company is responsible for solving it. These questions are more revealing than asking whether they would use a proposed application because they focus on behavior that has already occurred. A customer who describes a painful workaround, an expensive existing vendor or a failed internal project is providing stronger evidence than someone who simply agrees that the idea sounds useful.
Once the problem appears credible, create the smallest possible offer that allows people to express meaningful interest. For some products, this might be a landing page describing the benefit and showing pricing. For others, it might be a paid pilot, a manual service or a clickable prototype accompanied by a request for a concrete next step. The correct experiment depends on the uncertainty being tested. If the main risk is whether the problem exists, interviews may be sufficient initially. If the risk is whether customers will pay, the experiment must eventually ask for money or another meaningful commitment.
Finally, expose the offer to the people who actually represent the target market. Traffic from friends, curious developers or an unrelated online community may produce flattering numbers without answering the relevant question. A landing page for enterprise compliance software should be evaluated using people who make or influence enterprise compliance decisions, not a random audience attracted by an entertaining launch announcement. The purpose is to learn whether the intended customer wants the proposed outcome strongly enough to take the next step.
Why a Landing Page Is Not Enough
There is a temptation to treat Buffer's story as proof that every founder should build a landing page, collect email addresses and then begin development. That interpretation misses the most important part of Gascoigne's account. He explicitly emphasized that the landing page was valuable because it generated learning, not because it generated an impressive list of names.
A landing page can produce misleading evidence when the visitors do not represent the intended market or when the action being measured requires almost no commitment. A person might join a waitlist because the product sounds intriguing, then ignore every subsequent email. A pricing-page click may indicate willingness to consider payment without demonstrating actual willingness to complete a purchase. Even a paid pilot can be misleading if the customer is motivated primarily by a personal relationship with the founder.
Validation therefore requires interpretation. The founder must understand who responded, why they responded and what they were willing to do next. If a hundred students sign up for software intended for enterprise finance teams, the experiment may have demonstrated that the messaging appeals to students rather than that enterprise demand exists. If ten qualified buyers request demos but none will discuss pricing, the founder may have uncovered an interesting problem that does not yet justify a commercial solution.
The best experiments are designed to eliminate a specific uncertainty. They do not merely create activity that can be reported as progress. Gascoigne's use of pricing and personal follow-up made the original experiment more informative because it pushed beyond the easiest possible expression of interest.
The Hidden Distribution Advantage of Validation
There is another consequence of validating a product before building it that founders frequently overlook. The process can create the beginnings of a distribution channel. Every relevant person interviewed becomes someone who understands what the company is trying to solve. Every person who joins a carefully targeted waitlist becomes a potential early user. Every pilot customer becomes a possible source of feedback, evidence and introductions.
This changes the relationship between product development and customer acquisition. In the conventional sequence, the founder builds a product and then searches for people to use it. In the validation-first sequence, the founder begins meeting potential customers while discovering what the product should become. By the time the software is ready, there may already be a small audience that understands the problem and wants to try the solution.
The distinction becomes particularly valuable for B2B SaaS companies, where acquiring the first customer can require a substantial amount of trust. A founder who has spent six weeks speaking with operations managers about a reporting problem may have a much easier time finding initial users than someone who spent those same six weeks building a reporting application in isolation. The conversations create market knowledge, but they also create relationships that can eventually become distribution.
Buffer's early development reflected this connection. The landing page generated signups, but Gascoigne also communicated directly with many of those people. When the product launched, some were ready to use it because the company had not been entirely invisible during development. The founder was building a product and a small market relationship at the same time.
What to Measure Before Writing Code
The most useful validation metrics are those that reveal whether customers are moving toward meaningful commitment. A landing page's total visitor count can help establish the size of the experiment, but the number matters less than who visited and what they did. A hundred qualified visitors who understand the problem may provide more useful evidence than ten thousand people with no connection to the intended customer.
Email signups can demonstrate interest, but they should be interpreted alongside the actions that preceded them. Did visitors understand the product's value proposition? Did they examine pricing? Did they select a plan? Did they reply to follow-up messages? Were they willing to schedule conversations or describe their existing workflows? Each additional action provides context for the original signup.
For B2B products, the strongest signals often involve customers making commitments that cost them something. A prospect who introduces the founder to a budget owner is investing professional credibility. A company that agrees to share operational data for a pilot is investing time and trust. A customer who pays for a manually delivered version of the service is demonstrating that the promised outcome has economic value even before the software exists.
These signals should not be confused with guarantees. Early buyers can be unusual, and a few successful pilots do not prove that the wider market will behave identically. What they provide is a rational basis for deciding which assumptions deserve further testing and which parts of the product should be developed first.
When Validation Tells You to Stop
The most valuable outcome of a validation experiment is not always permission to build. Sometimes it is permission to abandon an idea before the costs become substantial. A founder may discover that the problem occurs only once a year, that customers already have an adequate workaround or that the person experiencing the pain has no influence over the purchasing decision. These discoveries can feel disappointing, but they are considerably cheaper than learning the same things after a year of development.
Other experiments reveal that the problem is real but the proposed customer is wrong. A founder building scheduling software for small restaurants might discover that independent owners are unwilling to pay while multi-location operators face the same problem at a much greater scale. The product idea may remain useful, but the market changes. Similarly, a company may discover that customers want the outcome but prefer a managed service to another piece of software they must operate themselves.
This is why validation should be viewed as a process of refining assumptions rather than obtaining a single positive result. The objective is not to collect enough encouraging feedback to justify the idea you already love. It is to discover which version of the opportunity survives contact with actual customer behavior.
A founder who abandons a weak idea after two weeks of research has not necessarily failed. They may have avoided spending a year building something that the market would never support. In entrepreneurship, preserving time and capital can be as important as finding the right opportunity, because those resources are what allow the next experiment to happen.
The Lesson Hidden in Buffer's First Customer
It is tempting to tell the Buffer story backward, beginning with the successful company and treating the landing-page experiment as the clever trick that made everything inevitable. But the founder standing in front of those early web pages in 2010 did not know that Buffer would become a recognizable software brand. He knew only that he had an idea, that previous experiences had taught him the cost of insufficient validation and that a few small experiments might help him decide whether the idea deserved more time.
The experiment did not eliminate uncertainty. It reduced it. People showed interest, some considered paid plans, and conversations revealed enough about the problem for Gascoigne to proceed. He then built a limited product, launched it and acquired a paying customer within days. The evidence accumulated gradually, with each step making the next investment more reasonable.
This is the deeper lesson for founders wondering how to validate a SaaS idea before building it. The purpose of validation is not to predict the future with certainty, because no experiment can do that. It is to replace some of the founder's assumptions with observable customer behavior before the cost of being wrong becomes enormous.
A founder can spend six months building an application and emerge with a product that nobody wants, or spend two weeks investigating a problem and emerge with a clearer understanding of what customers might actually buy. The second founder may appear to have accomplished less because there is less software to demonstrate. But if the investigation identifies a genuine problem, a reachable customer and a credible path to payment, that founder may already possess the more valuable asset.
They know what is worth building, and they have begun learning how to find the people who will pay for it.
Frequently Asked Questions About SaaS Idea Validation
How do I validate a SaaS idea without coding?
Begin by identifying a specific customer problem and speaking with people who experience it. Investigate how they currently solve the problem, what it costs them and whether they are actively searching for alternatives. Then create a simple offer, landing page, prototype or manual service that allows potential customers to demonstrate meaningful interest before you commit to developing software.
Can a landing page validate a SaaS idea?
A landing page can provide useful evidence of demand, particularly when it reaches qualified prospects and measures meaningful actions such as pricing-page visits, plan selections or requests for a pilot. However, email signups and clicks are weaker evidence than actual payment, so they should be combined with customer conversations and progressively stronger commitment tests.
How many customers should I interview before building a SaaS?
There is no universally reliable number because the appropriate sample depends on the market, the complexity of the product and the consistency of the findings. An initial set of ten to twenty well-targeted interviews can help reveal recurring problems, but founders should continue investigating until they understand the customer, the purchasing process and the strongest uncertainties well enough to design a meaningful test.
How do I test whether people will pay for my SaaS?
Present a concrete offer with pricing and ask qualified prospects to take a meaningful next step. This might involve selecting a paid plan, agreeing to a paid pilot, placing a refundable deposit or purchasing a manually delivered version of the outcome. A pricing-page click can indicate intent, but completed payments provide stronger evidence of willingness to pay.
Should I build an MVP before validating my SaaS idea?
Not necessarily. An MVP is an experiment designed to test an important business assumption, and that experiment does not always require functional software. Depending on the uncertainty involved, a landing page, prototype, manual service or paid pilot may provide useful evidence before the founder invests in product development.
What are the biggest mistakes in SaaS idea validation?
Common mistakes include interviewing people outside the intended market, asking hypothetical questions that invite polite encouragement, treating waitlist signups as guaranteed customers and building too many features before establishing demand. The most damaging mistake is designing experiments that confirm what the founder wants to believe instead of testing the assumptions most likely to make the business fail.
Sources
This article draws primarily on Joel Gascoigne's firsthand account, How to Successfully Validate Your Idea With a Landing Page MVP, in which he explains why the early Buffer website was designed for learning rather than simply accumulating signups. His account describes the conversations he had with prospective users, approximately 120 signups during the early period, around 50 users who adopted the initial product and the first paying customer shortly after launch.
Additional historical details come from Gascoigne's retrospective, Reflecting on 10 Years of Building Buffer, and his account of the features Buffer deliberately launched without. Together, these sources document the distinction between testing customer demand, building the smallest usable product and expanding development only after real customers began providing evidence.