Everyone says ship smaller. We scored 30,000+ companies taking real payments on how hard they are to build, and found the advice has a floor nobody mentions.
The most upvoted piece of MVP advice in the founder communities we track is four words long: “Just launch the damn thing.” It comes with a number attached, “6-8 weeks max for an MVP,” and it is repeated in some form in 82 separate discussions in our corpus.
It is good advice with a missing half. Everyone tells you to build less. Nobody tells you where the bottom is, so founders ship something trivially small, watch it get ignored, and conclude the idea was wrong.
We had a way to check where the bottom actually sits. Every company in our Stripe Index snapshot carries a buildability score, a 1-to-10 rating of how feasible the product looks to build. Cross that against which companies are classified as micro SaaS, and you get the shape of what one person can actually sustain.
Micro SaaS peaks at buildability 7, where 28.3% of companies qualify. At buildability 10, the most trivially buildable tier, it collapses to 2.3%. The easiest thing to build is not the thing that gets paid.
82 distinct discussions, and the phrasing barely varies. From r/microsaas: “At what point do you stop building and say, ‘This is good enough, I need feedback now’?” And: “How polished should the MVP really be?” And: “What would the simplest MVP need to include?”
From r/SaaS, the compressed version: “to MVP or not to MVP?” And the practical one: “Or do i build an MVP and get out there trying to prove value?”
From r/EntrepreneurRideAlong: “If you’re trying to validate an idea, do you need to build an MVP?” From r/buildinpublic: “Do you build an MVP first, create a landing page, run ads, conduct interviews, or something else?”
And the one that names the real constraint, from r/microsaas: “For solo builders who are actually shipping and making revenue, what is your current stack to get an MVP out the door before losing interest?”
Buildability is a 1-to-10 AI rating of how feasible a product appears to build, where 10 is trivially buildable and 1 is very hard. It is a judgement about apparent technical and operational difficulty, in the same family as the scoring behind the opportunity score.
It is not a quality score, not a market-size estimate, and not a prediction of success. A product can be easy to build and excellent, or hard to build and pointless. What it captures is the cost of entry.
Source is the Stripe Index, our AI-enriched snapshot of companies listed on Stripe’s public directory. Buildability is populated for all 30,322 companies, which is unusually complete for this dataset and the reason this analysis is possible at all.
The micro SaaS flag is a separate AI classification on the same records. Percentages below are the share of companies at a given buildability score that carry that flag. Queries re-run September 11, 2026.
| Source | Evidence type | Volume | Limitation |
|---|---|---|---|
| Buildability score | AI 1-10 feasibility rating | 30,322 (100%) | A model judgement, accurate in aggregate, occasionally wrong per company |
| Micro SaaS flag | AI classification | 30,322 | Definitional edge cases; treat the distribution, not the label |
| Price tier | AI classification | 12,261 known | Known for ~42%; unknown excluded rather than counted |
| Maturity signal | AI classification (indie / growing / established) | 30,322 | Inferred from public signals, not from revenue |
| Docs / API flags | Detected on company pages | 29,089 | Absence may mean undetected rather than absent |
| Complaint corpus | Capterra, G2, App Store reviews | Complexity-tagged subset | Capterra category coverage decays alphabetically |
| Reddit ICP corpus | Question sentences, ICP-filtered | 82 distinct posts on MVP scope | Illustrative, not representative |
| Buildability | Companies | Micro SaaS share | Has API | Has docs |
|---|---|---|---|---|
| 1 (hardest) | 867 | 0.0% | 49.1% | 3.7% |
| 2 | 6,502 | 0.2% | 49.9% | 3.6% |
| 3 | 6,091 | 0.4% | 49.7% | 4.6% |
| 4 | 5,473 | 1.5% | 45.7% | 5.1% |
| 5 | 3,463 | 6.4% | 41.7% | 5.6% |
| 6 | 3,511 | 18.6% | 39.2% | 6.4% |
| 7 | 2,099 | 28.3% | 39.5% | 4.9% |
| 8 | 1,418 | 23.3% | 40.4% | 3.4% |
| 9 | 677 | 13.7% | 44.2% | 2.8% |
| 10 (easiest) | 221 | 2.3% | 45.2% | 2.7% |
From 23.3% at buildability 8 to 13.7% at 9 to 2.3% at 10. The share falls by a factor of ten across the last two steps.
There are only 221 companies at buildability 10, and five of them are micro SaaS. Whatever is at that end of the scale, almost nobody has turned it into a small paid product.
The straightforward explanation is competition. If a thing takes an afternoon, it takes your competitor an afternoon too, and it takes the incumbent an afternoon to add it as a feature. There is no defensible position at buildability 10. That is the moat argument in SaaS moats in the AI era and the micro SaaS competition map.
The second explanation is willingness to pay. Buyers estimate effort, roughly and often wrongly, but they do estimate it. A product that visibly took a weekend struggles to justify a subscription. This connects to the pricing finding in what micro SaaS actually charges, where buildability and price tier move in opposite directions.
“Build less” is correct until roughly buildability 8, then it inverts. That is the missing half of the advice.
The practical read: if your first version genuinely takes a weekend, that is a signal to look harder at the problem, not a sign of admirable discipline. See single-feature micro SaaS ideas for what a defensible small scope looks like, and launching a micro SaaS in a weekend for the counter-argument.
Going the other way, micro SaaS falls off a cliff below 5: 6.4% at 5, then 1.5%, 0.4%, 0.2%, 0.0%. Buildability 1 through 4 accounts for 18,933 companies and effectively no micro SaaS.
That band is not a first version, it is a funded company. If your scope lands there, you are choosing a different game, described in startup ideas that get funded and what VCs are funding.
7,028 companies sit at buildability 6, 7 or 8, and 22.5% of them are micro SaaS, against roughly 5% across the whole index.
Translated: hard enough that shipping it is real work, easy enough that one person finishes it. That is about six to eight weeks, which is exactly the number the founder communities converged on independently. For what fits in that window see micro SaaS examples, the best micro SaaS ideas, and simple SaaS ideas for solo developers.
Average buildability by price tier: 5.11 free, 5.08 low, 4.39 mid, 3.66 high, 3.18 enterprise. A clean monotonic decline.
The market pays for difficulty. That is not a reason to make your product harder, but it is a reason to be honest that choosing an easy build is also choosing a price ceiling. Full price data in what micro SaaS actually charges and SaaS pricing strategies.
Average buildability: indie 4.47, growing 4.45, established 3.34. Indie companies (9,334 of them) build easier things than established ones (7,454).
Two readings, both probably true. Solo operators pick tractable problems. And products that survive long enough to become established tend to be ones that were hard to copy. See micro SaaS trends and SaaS market saturation.
| Category | Companies | Avg buildability | % in 6-8 band | % micro SaaS |
|---|---|---|---|---|
| creator-monetization | 408 | 6.27 | 48.0% | 10.8% |
| fashion-apparel | 248 | 5.67 | 44.4% | 2.0% |
| newsletters-publishing | 257 | 5.23 | 34.6% | 8.6% |
| ai-tools | 955 | 5.21 | 43.7% | 34.7% |
| data-analytics | 273 | 4.90 | 36.6% | 19.8% |
| courses-coaching | 1,065 | 4.86 | 33.0% | 3.6% |
| project-management | 239 | 4.65 | 31.8% | 15.9% |
| workflow-automation | 422 | 4.64 | 33.4% | 10.9% |
| crm | 351 | 4.48 | 27.4% | 6.6% |
| marketplace | 1,479 | 4.47 | 23.9% | 2.3% |
| ecommerce-platform | 3,452 | 4.41 | 25.9% | 0.8% |
6.27 average, with 48.0% of companies in the 6-to-8 band, the highest of any category. Yet only 10.8% are micro SaaS.
Buildable and crowded. This is the clearest illustration that the sweet spot is necessary and not sufficient. Compare with newsletter business ideas and subscription business ideas.
955 companies, 5.21 average buildability, 43.7% in the sweet spot, and 34.7% micro SaaS, the highest of any category by a wide margin.
AI tooling is currently the most accessible place to build something small that people pay for. It is also the fastest-moving, so read it alongside the AI SaaS revenue reality check, AI SaaS ideas, and SaaS moats in the AI era.
4.90 average with 19.8% micro SaaS, the second-highest micro share. Reporting and dashboard work is tractable for one person and genuinely wanted, which matches the demand evidence in industries still running on spreadsheets.
Ecommerce platforms: 3,452 companies, 0.8% micro SaaS. Marketplaces: 1,479 companies, 2.3%.
Both require something a first version cannot fake. A marketplace needs two sides to arrive at once; an ecommerce platform needs integrations nobody will wait for. These are the two clearest “not for your MVP” categories in the data.
The most upvoted advice in the corpus, from r/SaaS: “What actually works: Just launch the damn thing. 6-8 weeks max for an MVP.” And from the same community, the mindset version: “have an mvp mindset with everything you do.”
The community number and the data agree, which is rare enough to be worth noting. A buildability 6-to-8 product is roughly that much work.
“At what point do you stop building and say, ‘This is good enough, I need feedback now’?” The honest answer from this data: when the single workflow runs end to end, and not before.
Not when it is polished. Not when every edge case is handled. When one person can complete the job they came to do without leaving your product. That threshold is easier to spot if you already know the workflow you are replacing: finding problems to solve, daily frustrations that need an app, and turning problems into products.
“How polished should the MVP really be?” Polished enough to avoid the complaints that kill early products, which are not the complaints founders expect.
This is the clearest signal in the complaint corpus, and it inverts the usual MVP anxiety. Nobody writes a review saying “this does too little.” They write this:
“Walks you through about 30 pages before you can even start the app. Way too many features and options.” “Super over complicated to learn how to use, its just overwhelming.” “First it’s too complicated to understand. The developers really tried to make us have a hard time as users.”
And the terminal version: “Can’t find how to actually set this up! Too complicated so it’s worthless.” And: “Unpredictable and too complicated. Should be much easier to use. Doing my own data base.” That last one is a customer leaving for a spreadsheet.
The phrase recurs so often in the B2B corpus it functions as a category of failure. “Users report a steep learning curve and difficulty understanding how to utilize the platform effectively, which significantly affects productivity.” “Users experience significant challenges with the platform’s complexity, leading to a steep learning curve that impacts their ability to utilize its full capabilities.”
“Users struggle with a steep learning curve and insufficient training materials, resulting in decreased satisfaction and productivity.” “Users struggle with template management, integration limitations, and a steep learning curve, which impede efficiency and adoption.”
And the one that names the mechanism directly: “Users find the interface outdated and difficult to fully utilize due to feature overload.”
“The key issues point towards limited customization capabilities, a steep learning curve, and complex onboarding processes that impair user experience.” “Users find it overly complex, especially for new users, leading to frustration and inefficiencies in onboarding.”
A Capterra reviewer, an owner in retail, gives the commercial consequence: “I got NO business from this software. It was too complicated for me to figure out how it worked.” Another, in food and beverages: “Got zero customers from it.”
A founder in computer software, reviewing a tool they depended on: “The user interface can be overwhelming, and I’ve spent too much time fixing bugs rather than focusing on creating.” A studio manager: “It can get a little tricky to stay organized when managing a large number of students. The interface can feel a bit overwhelming at times.”
An App Store reviewer on a habit tracker: “I’ve lost a streak twice now because the very most basic feature, streak reminders, doesn’t work reliably. Finally done with this bloated mess.” The basic feature broke while the product grew.
Further reading on mining this signal: SaaS ideas from negative reviews, the most hated software of 2026, and customer review analysis.
The worst place to land is not too small or too big, it is half of a workflow. If your product handles steps one through three and the user still does four and five by hand, they are now running two systems instead of one.
That is the pattern behind most “export to Excel” complaints, documented at length in industries still running on spreadsheets. Narrow is fine. Partial is not.
Worth knowing before you add them to an MVP scope. Only 4.9% of 29,089 companies have documentation at all, and the share never exceeds 6.4% at any buildability level. API presence is roughly flat across the range, between 39.2% and 49.9%.
If you are debating whether v1 needs docs, the market has answered: overwhelmingly it ships without them. More on what buyers actually notice in the most requested software features and why SaaS customers churn.
From r/buildinpublic: “Do you build an MVP first, create a landing page, run ads, conduct interviews, or something else?” From r/SaaS: “What’s your process, landing page, manual outreach, mvp, something else?” And: “I keep seeing advice like: talk to people first, build a waitlist, launch an MVP fast, pre-sell before building. But what do people here do in practice?”
They test different things. A landing page tests whether the pitch lands. Only a working product tests whether the workflow holds and whether anyone comes back. See how to validate a startup idea, multi-signal validation, and common validation pitfalls.
From r/SaaS, the question that should be on a poster: “How many of you have built a perfect MVP and never launched it because you didn’t know how to get the first users?”
This is the failure mode the buildability data cannot see, because those products never reached Stripe. It is also the one our growth levers analysis found dominates at exit: 74.8% of founders selling a business said marketing was the untapped half.
The most useful single line in the whole corpus, from r/EntrepreneurRideAlong: “What helped me was treating the first version like a test, not ‘the business.’ Build the smallest thing you can put in front of 2-3 people this week.”
That reframes scope entirely. A test needs to be conclusive, not complete. Practical framings in customer discovery questions, validating before coding, and the SaaS idea validation tool.
One workflow, end to end. The import path, because every buyer has existing data. And a way to pay, because free users answer a different question than paying ones.
More on the build itself: how to build a SaaS in 2026, building with Next.js, Supabase and Stripe, what a micro SaaS boilerplate is, and the micro SaaS build guide.
Settings. Roles and permissions. A second workflow. Documentation, per the 4.9% figure. Integrations beyond the one your buyer already uses. Anything that exists because a competitor has it.
The complaint corpus is unambiguous that each of these, added early, reads to users as complexity rather than capability.
Every step up the buildability scale is a step down in defensibility. At 10 anyone can copy you; at 3 almost nobody can, but you also cannot finish it alone.
6 to 8 is where that trade balances for one person. See micro SaaS with no API dependency and the micro SaaS competition map.
Creator monetisation is the most buildable category and only 10.8% micro SaaS. Ecommerce is harder and only 0.8%. Buildability tells you whether you can finish, not whether anyone pays.
Cross-reference demand before committing: business pain points, tools to find pain points, and SaaS ideas backed by pain points.
Getting scope right solves the smaller half of the problem. Our analysis of businesses that sold found distribution, not product, was the unfinished half in the large majority of cases.
Budget for it before you finish building: your first 100 SaaS users, how to get customers, and where to launch.
Rough self-assessment. Could a competent developer ship a working version in a weekend? That is a 9 or 10, and the data says reconsider. In six to eight weeks? That is your 6 to 8. Does it need a team, a data partnership, or regulatory work before anyone can use it? That is 4 or below, and it is a different kind of company.
One r/microsaas question contains a constraint the whole literature ignores: “For solo builders who are actually shipping and making revenue, what is your current stack to get an MVP out the door before losing interest?”
Motivation is a real scoping input for a solo operator, and it decays on a timescale that looks a lot like six to eight weeks. A buildability-4 project is not just harder, it is more likely to be abandoned mid-build, which is the single most common way a first version dies.
Related reading on keeping scope inside one person’s attention span: one-person business ideas, the solopreneur SaaS toolkit, free tools for indie hackers, and side hustles for developers.
A r/microsaas commenter asks whether the shortcut kits work at all: “Honestly curious, has anyone ever seen a decent project shipped off the back of one of these ship fast type kits?”
Boilerplates move you up the buildability scale by removing auth, billing and deployment work. That is useful if it gets you from a 4 to a 6. It is a trap if it gets you from a 7 to a 10, because it deposits you in the part of the distribution where almost nobody is charging for anything.
See the best Next.js SaaS boilerplates, ShipFast alternatives, and starter kits with auth and payments.
One r/EntrepreneurRideAlong question reframes scope as a purchase decision: “If you’ve bought a small SaaS tool, an MVP, or pre-built software instead of building in-house: what made you comfortable pulling the trigger?”
And from r/startups, the arbitrage version: “Is it possible to perpetually build and sell startups as MVP after few months of operations?” Our acquisition data says the margin on that is thinner than it looks, because young businesses sell at the same multiple as old ones, just on a smaller number.
See buying vs building a SaaS, finding acquisition targets, the state of SaaS acquisitions, and SaaS valuation multiples.
A r/SaaS commenter, on the gap between expectation and reality: “What’s wild is realizing how small the early momentum actually is.” And another framing the whole exercise in one line: “have an mvp mindset with everything you do.”
That matches the timeline evidence. Median revenue for a business at one year old, among those that got far enough to be worth selling, is about $5,167 a month. The first version is not supposed to feel like a business yet.
Context: how long it takes to grow a SaaS, startup failure statistics, the state of indie SaaS revenue, and TrustMRR revenue benchmarks.
Buildability tells you what you can finish. Segment tells you whether anyone in that band pays. Micro SaaS concentrates in the two smallest customer segments, developers at 20.9% and prosumer at 16.8%, not in the SMB and mid-market segments most founders target: who micro SaaS actually sells to.
Buildability is populated for all 30,322 companies, so there is no coverage gap on the primary variable, which is unusual for this dataset. Price tier is known for only 12,261 (~42%), so the price-tier finding rests on a smaller and likely self-serve-biased subset.
Companies that never reached Stripe are absent entirely, which removes exactly the products that were built and never launched.
Buildability is a model judgement. Useful in aggregate, unreliable per company.
It reflects apparent difficulty from a public page, not the real engineering.
Correlation, not causation. Micro SaaS concentrating at 6-8 does not prove building at 7 makes you a micro SaaS.
Survivorship. Every company here reached Stripe. Abandoned MVPs are invisible.
Selection bias. Stripe’s public directory skews digital, self-serve and English-language.
Snapshot. September 2026, no time series, so it cannot show whether the sweet spot is moving.
Filter the index to your category and read the buildability distribution against the micro SaaS share. Start at the Stripe Index database, companies using Stripe, or discover. The complaint analysis guide and MCP server cover the rest.
For context from outside our data, MicroConf’s State of Independent SaaS surveys bootstrapped founders directly, the Y Combinator library is the canonical source for launch-early advice on the funded path, acquire.com shows what these products eventually sell for, and the US Census Business Dynamics Statistics gives the economy-wide survival baseline.
30,000+ scored companies, 1M+ documented complaints, and real revenue benchmarks, filtered by the category you are actually considering.
Start searching →Smaller than a platform, larger than a weekend script. Micro SaaS concentrates at buildability 6 to 8, peaking at 7 (28.3%). Below 5 it is 0% to 1.5%; at 10 it is 2.3%.
Yes. At buildability 10 only 2.3% of companies are micro SaaS, lower than anywhere between 5 and 9. If anyone can build it in an afternoon, there is usually no business in it.
Six to eight weeks is both the most upvoted community answer and roughly what a buildability 6-to-8 product takes.
It commands a higher price: average buildability falls 5.11 free, 5.08 low, 4.39 mid, 3.66 high, 3.18 enterprise. But the hard end is not micro SaaS territory.
A 1-to-10 AI rating of apparent feasibility, 10 being trivially buildable. Not a quality or market-size score.
Creator monetisation (6.27 average, 48.0% in the sweet spot), then AI tools (5.21, 43.7%), which also has the highest micro SaaS share at 34.7%.
Ecommerce platforms (4.41, 0.8% micro SaaS) and marketplaces (4.47, 2.3%). Both need two-sided supply or heavy integrations a first version cannot fake.
A landing page tests the pitch; only a product tests the workflow and retention. They answer different questions.
Polished enough to avoid complexity complaints, which are the ones that actually kill early products.
Too many. The corpus is full of overwhelming, too complicated and feature-overloaded. Complaints about one missing feature are far less fatal.
Docs are near-absent everywhere: 4.9% overall, never above 6.4% at any buildability level. API presence is roughly flat at 39% to 50%.
No. It is where micro SaaS concentrates, not where profit is. Creator monetisation is the most buildable category and only 10.8% micro SaaS.
One workflow end to end, the import path, and a way to pay. Partial coverage of a workflow is worse than none.
Indie averages 4.47 buildability and established 3.34. Established products are meaningfully harder to build.
Yes. Every step up in buildability is a step down in defensibility. 6 to 8 is where that trade balances for one person.
An AI classification applied uniformly across 30,322 companies. Useful in aggregate, occasionally wrong per company. Treat the distribution as the finding.
BigIdeasDB indexes the Stripe Index alongside complaint and revenue data. Start at the Stripe Index database or discover. Further reading: micro SaaS ideas for 2026, micro SaaS examples, the best micro SaaS ideas, simple SaaS ideas for solo developers, low competition SaaS ideas, the first $1K MRR, solo developer revenue examples, the solopreneur toolkit, how to find startup ideas, problem-solving app ideas, business ideas that solve real problems, and how to find problems worth solving.
BigIdeasDB Research. (2026). How Small Should Your MVP Actually Be? (30,000+ Companies). BigIdeasDB. Retrieved from https://bigideasdb.com/how-small-should-your-mvp-actually-be