Is your SaaS idea a business or a feature?
Six tests to run before you build, to find out whether your idea can stand alone as a company or only works as a capability inside someone else's product.
Plenty of useful software is not a company. A feature solves a real problem, but it solves it inside a workflow somebody else owns, for a buyer who will not pay for it on its own. A business solves a problem that someone budgets for, in a way that does not depend on the goodwill or the roadmap of a larger product. The difference is hard to see from the inside, because the feature feels complete and the demo works.
This article gives you six tests. None of them needs code. All of them can be run in a few weeks by one founder with a phone, a spreadsheet and the willingness to hear an unwelcome answer.
What “feature” and “business” mean here
We use the words in a narrow, practical sense.
A feature is a capability that is valuable only in combination with something the customer already uses and already pays for. If the host product adds the same capability, the customer has no reason to buy yours.
A business is a product with its own buyer, its own budget line and its own reason to exist when nothing else changes. The customer would notice, and mind, if it disappeared.
Many good companies begin as something that looks like a feature. The question is not whether you start small. It is whether there is a path from the small start to something with its own gravity. Paul Graham’s essay on startup ideas makes a related point: aim at a small group of people who need the thing a great deal rather than a large group who mildly like it, because the first group can grow into more. Narrow is fine. Optional is the problem.
The six tests
| Test | The question | Evidence you can gather in weeks |
|---|---|---|
| 1. Buyer | Who writes the check, and from which budget? | Name the role. Ask three people in that role what they spent on this problem last year and who approved it. |
| 2. Standalone job | Does the job get finished using only your product? | Walk the job from trigger to done on paper. Mark every step that needs another tool. |
| 3. Urgency | What happens if the customer does nothing? | Ask what the problem cost the last time it bit. Look for a workaround that already costs money or time. |
| 4. Host risk | Could the platform you depend on ship this? | List the products you plug into. Read their public roadmaps and release notes for adjacent work. |
| 5. Distribution | How do customers find you without the host? | Name two channels that work if the host never mentions you. |
| 6. Repeat need | Does the problem come back on a schedule? | Ask how often the trigger happens. A one-off need is a project, not a subscription. |
Test 1: Is there a buyer with a budget?
Software that users love and nobody purchases is common. Find the person who would sign. Then find out what the problem currently costs them in a way they can name: staff hours, a contractor, a missed deadline, a tool they already pay for and resent. If every conversation ends at “it would be nice”, you have found a preference rather than a budget.
Test 2: Does the job finish inside your product?
Jobs-to-be-done thinking, popularised by Clayton Christensen and colleagues, asks what progress the customer is trying to make rather than what features they say they want. Draw that job as a short sequence from the moment something triggers it to the moment the customer considers it done. Count the steps your product covers. If you cover one step out of seven and the other six live in a tool the customer already loves, you are probably building a feature of that tool.
This is not an automatic failure. An integration-first product can be a real business when the step it owns is painful enough and the customer pays for that step directly. What matters is whether you own an outcome or merely a button.
Test 3: What does doing nothing cost?
The strongest signal of a real business is a customer who is already paying, in money or in effort, to solve the problem badly. A spreadsheet that three people maintain every Friday is a stronger signal than any amount of enthusiasm. Ask for the last occurrence, not the hypothetical one: when did it last go wrong, what did you do, what did that take.
Test 4: Could the host ship this next quarter?
If your product depends on a platform, a marketplace or a larger application, assume the owner can see what you see. Read what they publish about direction. Ask yourself whether your advantage is a capability they could add or a relationship, a data position or a depth of focus they are unlikely to match. We cannot tell you the odds, and neither can anyone else with confidence. We can tell you to write the answer down, so that you are choosing the risk rather than discovering it.
Test 5: Can you reach customers without the host?
A feature that is found only through the host’s marketplace has a distribution problem as well as a dependency problem. List two ways a stranger would learn your product exists that do not route through the platform. If you cannot name two, either the market is smaller than you think or you have not yet found the channel. Both deserve a note in your problem brief.
Test 6: Does the need come back?
Subscription software is a bet that the need recurs. Ask how often the trigger happens and what the customer does between occurrences. Some valuable problems occur once, such as a migration or a launch. They make good services and poor subscriptions. That can still be a business, but the revenue model and the sales effort are different, and it is better to know before you design pricing.
A two-week way to run them
Spend the first few days on desk work: tests 2, 4 and 5 need reading, not conversations. Draw the job, list the host products and read what they publish, and write down the channels you believe in. Spend the rest of the first week booking conversations for tests 1, 3 and 6. Use the second week to hold them, and write up each conversation the same day, while you still remember what was said and what was merely implied. At the end, fill in the table with strong, weak or unknown for each row, and attach the evidence to each cell. If a cell has no evidence, it is unknown, whatever your instinct says.
Reading the results
Score each test as strong, weak or unknown. Do not average them. A single decisive weakness, such as no identifiable buyer, outweighs five strengths, because it describes the whole company rather than one part of it.
Unknown results are where the work is. Each unknown is a conversation you have not had yet. The next article on this desk, on customer discovery interviews, covers how to hold those conversations without collecting polite encouragement. The Lean Startup literature frames the same discipline as validated learning: treat each unknown as a hypothesis, decide what evidence would settle it, and look for that evidence before building more.
Turning the answers into a brief
Write the answers on one page: the buyer, the job, the urgency, the host risks, the channels and the frequency, each with the evidence you have and the evidence you lack. That page is the problem brief described later on this desk. It is also the document a technical team needs before it can estimate anything, which is why World Enterprise asks for it at the start of an engagement.
What this article cannot tell you
These tests are a structured way to ask questions. They are not a predictor. We have not measured how well they forecast outcomes, and we do not claim they do. They will not tell you whether your team can execute, whether the timing is right, or whether a market you cannot see yet is forming. They also reflect a bias toward products that sell to businesses with identifiable budgets, which is the world most SaaS companies live in but not the only one.
A negative result is information, not a verdict. It may point to a different customer, a different first step or a different idea. What it should prevent is the quiet assumption that because something works, someone will pay for it.
In the data
These figures describe U.S. businesses in general, not WE’s results. Each one names its source.
Show the data as a table
| Year | New employer firms (age 0) |
|---|---|
| 1978 | 488,103 |
| 1979 | 473,471 |
| 1980 | 439,667 |
| 1981 | 430,100 |
| 1982 | 418,627 |
| 1983 | 456,610 |
| 1984 | 529,584 |
| 1985 | 512,439 |
| 1986 | 517,516 |
| 1987 | 513,574 |
| 1988 | 507,091 |
| 1989 | 502,558 |
| 1990 | 493,080 |
| 1991 | 450,750 |
| 1992 | 438,701 |
| 1993 | 461,135 |
| 1994 | 475,989 |
| 1995 | 495,030 |
| 1996 | 493,289 |
| 1997 | 494,483 |
| 1998 | 477,206 |
| 1999 | 451,218 |
| 2000 | 446,204 |
| 2001 | 436,993 |
| 2002 | 455,162 |
| 2003 | 467,532 |
| 2004 | 505,056 |
| 2005 | 518,727 |
| 2006 | 541,317 |
| 2007 | 509,517 |
| 2008 | 471,285 |
| 2009 | 395,235 |
| 2010 | 379,145 |
| 2011 | 395,680 |
| 2012 | 408,546 |
| 2013 | 405,350 |
| 2014 | 411,948 |
| 2015 | 421,155 |
| 2016 | 442,414 |
| 2017 | 439,859 |
| 2018 | 442,078 |
| 2019 | 453,027 |
| 2020 | 455,725 |
| 2021 | 485,256 |
| 2022 | 521,312 |
| 2023 | 508,777 |
A startup here is a new firm with at least one paid employee; businesses with no employees are not counted.
Source: U.S. Census Bureau, Business Dynamics Statistics, firm age , 1978 to 2023
Retrieved 2026-10-16. Values are the published firm counts at firm age 0, copied as printed.
Sources
- How to Get Startup Ideas, Paul Graham . Accessed October 6, 2026.
- Know Your Customers' "Jobs to Be Done", Harvard Business Review . Accessed October 6, 2026.
- The Lean Startup, principles, Eric Ries, theleanstartup.com . Accessed October 6, 2026.
Spotted an error? Read how we handle corrections in our editorial policy.