I can build anything but don't know what to build: where developers should look, with revenue data

The short answer

This page is for developers and technical founders who are stuck one step before the idea. It uses TrustMRR verified revenue, the Stripe Index of companies already taking payments and the customer complaints in our software review research, part of a 1M+ complaint corpus. It does not list ideas; for that, see 15 simple SaaS ideas for solo developers.

What the top results say, and what they skip

Search this phrase and the first page is a coding-forum thread, a developer blog post asking what to build when you can build anything, an older beginner forum question, a long-form essay about not needing to know yet, a Q&A answer and a game forum with a list of castle ideas. Most of the advice is about starting. Build something small, scratch your own itch, contribute to an open-source tool, keep a notebook of ideas. That is good advice for learning. It is not advice for finding something people pay for, and none of those pages measures what people pay for.

The threads where developers describe the problem in business terms tell a different story. One full-stack engineer with a computer engineering degree wrote that execution is not their bottleneck and that they had spent months failing to find a valid idea. The thread drew 297 comments. A former technical co-founder asked the same thing in another thread: they can build anything and have no idea what to actually build. A backend engineer who left a large tech company posted it a third time, and a coding-forum thread says it for beginners. The wording changes. The shape does not.

““can i build it” filters out nothing because the answer is always yes.”comment in an r/SaaS thread from a technical founder

That sentence is the whole problem. When skill stops being a constraint, nothing forces a decision. The rest of this page replaces the missing constraint with three measurable ones: does the category pay, what do its customers hate, and how many products already serve it.

Why being able to build makes the search harder

The engineer in the 297-comment thread listed five reasons every idea they evaluated died: heavy regulation, a product people like but will not pay for, saturated markets, platform risk and new categories that need customer education. Each of those is a real risk. Together they guarantee that nothing passes, because every market has at least one. A commenter put it this way:

“You are suffering from the “curse of competence.” Because you understand exactly how and why startups fail, you are filtering out every single idea before it even breathes.”comment in an r/SaaS thread

A better filter does not remove risk. It checks which risks the data already answers. Take three of the five.

• “Zero true demand.” Measurable. If peers in a category reach $1,000 a month in verified revenue, buyers pay. If almost nobody does, the objection is real. The sections below show which categories are which.
• “Saturated bloodbath.” Also measurable, and usually misread. One commenter said saturation just proves people are already opening their wallets for a solution. Another replied that saturation proves demand existed when the incumbents entered, not that a new solo entrant can reach customers cheaply today. Both are partly right, which is why you check density and complaints together instead of arguing about it. Our crowded-market study found median revenue does not fall as a category gets more crowded.
• “Platform risk.” Visible in the complaints. If customers complain that the platform’s own feature is weak, a native release is a threat. If they complain about something the platform has ignored for years, it is a gap.

Regulation and net-new categories are different: data does not remove them, so a solo developer is right to avoid both while looking for a first product.

Developers tend to build what they use: tools for developers, productivity apps, small utilities, and increasingly AI products. Business owners tend to pay for something that moves a number: leads, sales, reporting, orders. We checked how each group of categories earns. We took every TrustMRR startup with a monthly revenue figure above $0 and a category, and kept the 20 categories with at least 30 earning startups. Nine are shown here.

The gradient is steep. Productivity has 223 earning startups and a median MRR of $46, with 7.6% reaching $1,000 a month. Sales has 38 and a median of $640, with 42.1% reaching $1,000. Marketing, with 213 earning startups, reaches $10,000 a month 10.3% of the time against 1.8% for productivity. Sales is a small group (n = 38), so read it as a direction, not a ranking. Marketing (n = 213) and productivity (n = 223) are large enough to trust.

Grouping the categories makes the same point with larger samples.

Developer tools deserve a note, because they look like the exception. 68% of earning developer-tool startups label themselves B2B, yet the median MRR is $68 and 18.2% reach $1,000. Narrow to developer tools labelled B2B and it barely moves: n = 113, median $74, 20.4% at $1,000+. So the label is not the whole story. One reading is that developers are a hard audience to charge, because they can build the thing themselves. We cannot prove that from this data, but it fits the pattern: the closer a product is to a developer’s own workflow, the lower its median revenue.

The practical use of the table is as a filter, not a verdict. Do not rule out developer tools or productivity because the medians are low; the top of every category is far above its median. But if your goal is a first product that reaches $1,000 a month, the odds in the business-function group are about 2.4 times those in the builder-for-builders group (27.3% against 11.4%).

Category is one lever. The buyer is another. Of the earning startups with at least one active subscription, we compared revenue per paying subscription by the audience each founder chose. B2B products earn a median $28.6 per active subscription. B2C products earn $9.0.

Do the arithmetic at the median. Reaching $10,000 a month takes about 1,100 paying B2C subscriptions ($10,000 divided by $9.0) or about 350 B2B ones ($10,000 divided by $28.6). The B2B group also reaches $10,000 a month 7.7% of the time against 3.5% for B2C, about 2.2 times as often. Since a developer’s time is the scarce input, a product that needs 350 customers instead of 1,100 is a different business to sell, support and keep alive.

We do not read the unlabelled row (740 startups, 10.7% at $10,000+) as better than B2B. It is a mixed group, and it includes older products whose founders never chose a label. Treat it as noise around the two clean groups. We go deeper on why audience changes the sums in our TrustMRR revenue benchmarks, and on the consumer side in B2C SaaS ideas.

Density, not company count, is the saturation signal. A category with thousands of businesses and almost no software products is not saturated. It is full of operators and empty of tools. We used the Stripe Index, a directory of 30,000+ companies already taking payments, where each company is classified by whether it is a micro-SaaS product.

AI tools and apps have 955 companies and 331 micro-SaaS products, a 34.7% share. That is where most developers look first, and it is where a new product meets the most direct neighbours. Home services and trades have 963 companies and 4 micro-SaaS products, a 0.4% share. Salons (3.1%), restaurants (3.0%), logistics (3.2%) and health and medical (3.7%) look similar. Invoicing and billing (13.5%) and accounting (12.1%) already have a software layer.

This is a supply count, not proof of demand, and a low share can mean either an opening or a market that does not buy software. That is why density is the third check, after revenue and complaints, and not the first. A thin category with unhappy customers who pay is the target. A thin category where nobody pays is the trap. For a longer view of this idea, see our research on what software to build to make money.

Once a category passes the revenue and density checks, the next question is what its customers wish the products did. Our software review data holds 40,000+ feature gaps across 13,000+ products, and 24,000+ of them (60%) are flagged as high or critical demand. Free-text labels vary, so we merged near-duplicates by hand. The most requested missing feature groups are below.

Read this as a developer. Reporting, integration, analytics and data management together make up the largest share of what customers say is missing, and they are the kinds of problem a skilled solo builder can solve in a weekend or two: pull data from two systems, clean it, show one useful view. That is why the commenter who said “they just need two things connected together” was describing demand, not only advice. It also matches the gaps in our state of SaaS pain points research.

Volume matters less than repetition. One complaint is an anecdote. The same complaint across hundreds of customers of the same product is a signal, and it is the one you can quote back to them. Use the complaints database to see the exact words.

The 5-day method

This is what we would run before writing any code. Five days, one person, no audience required.

1. Day 1: choose three categories where buyers pay. Use TrustMRR to rank categories by median revenue per paying subscription and by the share earning $1,000 a month. Prefer a B2B buyer and a business-function category. Drop anything where almost nobody earns. Write down the three.
2. Day 2: read the complaints about the incumbents. In the software review complaints, open the leading products in each category. Keep only complaints repeated by many customers that you could fix with one or two weeks of building. Copy the wording, not your interpretation.
3. Day 3: check density. In the Stripe Index, count the companies taking payments in each category and how many are micro-SaaS. Thin supply plus repeated complaints plus earning peers is the combination to look for. Cut the weakest category.
4. Day 4: write one wedge sentence and a price. The buyer, the one problem, the price and what it replaces. For example: “For dental practices, a flat monthly price to merge appointment and billing exports into one weekly report.” Then list ten people who wrote that complaint in their own words.
5. Day 5: ask for money before you build. Message the ten with the sentence and the price. Offer a paid pilot or a deposit. Count payers, not compliments. If two or three say yes, open the editor. If none do, you have lost five days, not five months.

For reaching those ten people in public forums without being removed, follow how to find customers in forum communities. For a stage-by-stage version of the testing step, use the idea validation framework. If you want the whole check for a specific niche in one place, run it through BigIdeasDB discover.

Worked example: from a blank page to a wedge

This is an illustration, not a case study. Suppose you are a backend engineer with no domain and a few weekends. Use the method.

1. Pay. Sales is one of the categories that pays: 38 earning startups in TrustMRR, a median MRR of $640, 42.1% at $1,000+ and a median $75.5 per paying subscription. Sales is a small group, so you also check marketing (n = 213, median $276, 28.6% at $1,000+) and reach the same direction. You keep both.
2. Complain. In the review data for sales and marketing tools, reporting and integration gaps repeat across many products. You read the actual reviews for three of them. The common line is a version of “I export it to a spreadsheet every week to see what is working.”
3. Density. You check lead generation (532 companies, 9.4% micro-SaaS) and CRM (351 companies, 6.6%) in the Stripe Index. Neither is empty, and neither is saturated with small tools.
4. Wedge. “For small agencies, one weekly page that pulls leads from their form tool and their CRM, flat price.” Not a CRM. One page, one buyer.
5. Ask. You message ten people who wrote the spreadsheet complaint. Three agree to a paid pilot.

The point is not that this idea is right. It is that every step ends in a number or a yes, and the cost of finding out you are wrong is five days. The alternative, building first and hoping, is the path the forum threads describe in their first line.

What about solving your own problem?

The most common advice in those threads is to solve your own problem, or to build in a space you know. It is good advice with one gap. Your own problem is a hypothesis about where a paid problem might be, not a result. One commenter said it plainly:

“Honestly, finding a problem that people are willing to pay for is the biggest bottleneck.”comment in an r/SaaS thread from a technical founder

Use your own friction to pick where to look, then run the same checks as anyone else: does the category pay, do its customers complain, can you reach ten of them. A developer who spent years banging their head against a problem in a regulated field has an advantage the data cannot give: they can judge a complaint. A developer who only heard a neighbour grumble does not. Another commenter in the same thread put the second option well: team up with someone who has the problem and lacks the code.

A coding-forum commenter gave a simple form of the same advice: stop thinking about ideas and start thinking about problems, and have ten real conversations. The only change we make is that you read the paid evidence first, so the ten conversations are with the right people. For a related approach with no code-first bias, see I want to start a business but have no ideas, and the help guide to finding problems worth solving.

When this advice does not apply

• You want to learn, not earn. A coding-forum thread is full of good project ideas for exactly this: a graphics toy, a tool for a chore you hate, a contribution to open source. Skip the method and build.
• You already have a customer. If someone is offering to pay you for a specific tool, build it. You are past the search.
• You want to work for money, not own a product. A freelance or agency route can be the right answer, and several commenters chose it. See side hustles for developers for the trade-offs.
• You are scared of competition. The method assumes you will meet it. If an incumbent earns, that is a reason to look closer, not to leave. Our study on crowded markets covers what to do next.

Where this page fits

Four nearby pages cover different questions. What software to build to make money ranks categories by sales. Simple SaaS ideas for solo developers lists specific ideas with revenue proof. Side hustles for developers compares routes beyond SaaS. Someone already built my idea is for the moment you find a competitor. This page covers the step before all four: how a skilled builder finds a problem worth paying for in the first place.

What this cannot tell you

• TrustMRR is a self-selected set. It lists startups whose founders connected a payment provider. It over-represents small, young, indie products and does not show profit.
• Audience labels are chosen by founders. A startup may label itself B2B and sell to individuals. We use the label as given, and 740 startups have none.
• Revenue per subscription is a blend. It divides monthly revenue by active subscriptions, so it mixes pricing tiers, and it excludes one-time sales.
• Category medians are not forecasts. The top of every category is far above its median, and a median says nothing about your product.
• Our group definitions are a choice. We chose which categories count as builder-for-builders and business functions. Other groupings would shift the numbers. The direction held across individual categories.
• Stripe Index is a keyword-bounded sample, not a census. It has no revenue. The micro-SaaS flag is our AI classification, and a low share can mean a gap or a market that does not buy software.
• Feature-gap labels are free text. We merged near-duplicates by hand, and counts are rounded. They show direction, not exact shares.
• Forum quotes are opinion. They show how developers describe the problem, not what works.

Methodology and sources

Revenue figures use TrustMRR monthly recurring revenue in US dollars, kept where above $0, and medians use at least 30 startups. Per-subscription figures use startups with one or more active subscriptions. Company counts come from the Stripe Index and feature gaps from our software review dataset. Everything was read with read-only SQL on October 22, 2026. Medians show n; cuts under 30 are not shown, apart from one flagged small group.

Frequently asked questions