Solo Founders: What Not to Build

Deciding what not to build is the most important product decision a solo founder makes. You should build only the smallest feature set that solves one clear problem for a specific group of people, and explicitly say no to everything else until those users confirm they need it.

Formula

Total dev cost = time to build (weeks) × dev cost per week ($/week). Monthly revenue = expected users (people) × price per user per month ($/user/month). Payback time (months) = total dev cost ÷ monthly revenue.

Variables: t = weeks of development, d = weekly cost (dollars), u = expected users, p = monthly price (dollars). All inputs are positive numbers; the formulas are simple multiplications and a division.

Worked Example

Using the default values: t = 8 weeks, d = $1500/week, u = 100 users, p = $10/month.

1. Total dev cost = 8 × 1500 = $12,000.
2. Monthly revenue = 100 × 10 = $1,000.
3. Payback time = 12,000 ÷ 1,000 = 12 months.

So with these assumptions, the feature pays back in one year. If the payback is longer than you can afford, do not build it.

Why “What Not to Build� Matters More for Solo Founders

A solo founder has one pair of hands, one brain, and a finite amount of time and money. Unlike a team, you cannot parallelize work or delegate unwanted tasks. Every feature you add is a direct opportunity cost: the hours you spend on it are hours not spent on marketing, customer support, or improving the core product. A common failure mode is building a “platform� with many features before validating that anyone wants the core. For example, a solo developer might spend three months adding social login, a mobile app, and an API, only to discover that the basic web tool they started with doesn’t solve the user’s real problem. Starting with a focused MVP (minimum viable product) and deliberately skipping everything else is the only sustainable path.

How to Decide: A Practical Framework

Use a simple scoring system for every potential feature. Write down the feature, then ask three questions:

• Does it directly solve the core problem? If not, it’s a distraction.
• Will a significant portion of your target users actually use it? “Nice to have� is not enough.
• Can you postpone it without breaking the core experience? If yes, postpone it.

Score each feature from 1 to 5 on each question. Add the scores. Only build features that score 12 or higher (out of 15). Anything below that goes on a “backlog� list that you revisit only after the core is stable and users ask for it.

Common Mistakes That Lead to Overbuilding

Solo founders often fall into predictable traps:

• Building for hypothetical users: You imagine a user who needs advanced features, but you haven’t talked to any real users. Talk to at least 10 potential users before writing code.
• Premature optimization: Spending time on scalability, caching, or microservices when you have fewer than 100 users. Use a simple, monolithic setup until you have real traffic.
• Feature creep from competitors: You see a competitor with a feature and feel you must match it. But your competitor has a team and funding; you have limited resources. Focus on your differentiator.
• Ignoring the “cost of maintenance�: Every feature you ship is something you must maintain, update, and support. A feature that takes 2 weeks to build might require 2 hours per month in maintenance forever. Calculate that into your decision.

How to Say No (and Still Keep Users Happy)

Saying no doesn’t mean being rude. It means setting clear expectations. When a user requests a feature you don’t plan to build, respond with a short explanation: “We’re focusing on improving the core experience right now, and I’ve added your request to our roadmap.� Then actually keep a public roadmap so users can see what’s coming. This transparency builds trust. For internal decisions, write a one-line rationale for why you’re not building something. For example: “We’re not building a mobile app because our users primarily use desktop and we need to validate the web version first.� This helps you stay consistent and avoid flip-flopping.

Costs of Building the Wrong Thing

The most obvious cost is time and money. But there are hidden costs: opportunity cost (what you could have built instead), cognitive load (more features mean more complexity in your head), and user trust (if you build a half-baked feature, users may lose confidence). A solo founder’s biggest asset is focus. Every unnecessary feature dilutes that focus. For example, adding a complex reporting dashboard might take two weeks, but those two weeks could have been spent on fixing a critical bug that’s causing churn. The payback calculator above gives a rough financial view, but the non-financial costs are often larger.

Alternatives to Building

Before you build a feature, consider whether you can achieve the same outcome without writing code:

• Use an existing tool: Instead of building a custom email integration, use Zapier or a similar service.
• Manual work: For a small number of users, you can manually perform the task (e.g., sending a daily report) until it becomes painful.
• Partner or outsource: Sometimes a freelance developer can build a feature cheaper than you can, freeing your time for higher-level strategy.
• Do nothing: Often the best decision is to not build anything and see if the problem disappears or becomes urgent.

These alternatives let you test the value of a feature without committing to full development.

Frequently Asked Questions

Q: How do I know if a feature is “core� or “extra�?
A: Ask yourself: if this feature were missing, would the product still solve the main problem? If yes, it’s extra. For example, for a to-do app, the core is adding and checking off tasks. A calendar view is extra.

Q: What if I have a great idea for a feature but no users have asked for it?
A: That’s a strong signal to not build it. If you believe in it, first validate with a simple survey or a landing page that describes the feature and measures sign-ups. If fewer than 30% of your target users show interest, skip it.

Q: How do I handle a user who is very vocal about a feature I don’t want to build?
A: Thank them for the feedback, explain your current focus, and ask them what problem they’re trying to solve. Often the underlying problem can be solved in a simpler way. If not, keep them informed if you ever change your mind.

Q: Is it okay to build a feature just because it’s easy?
A: Easy features are tempting, but they still add maintenance and complexity. A simple feature that no one uses is worse than no feature at all because it clutters the interface and confuses users. Only build easy features if they align with your core problem.

Q: How do I avoid feeling like I’m missing out by not building more?
A: Remind yourself that successful products are often minimal. Many well-known apps started with a single core function and added features later. Write down your long-term vision and check that each feature you build moves you closer to that vision, not just to a longer feature list.

Q: What if my competitors have a feature and I don’t?
A: Competitors often have features that are rarely used. Instead of matching them, talk to your users about what they actually need. If they consistently ask for that feature, then consider it. Otherwise, ignore it.

Related

• Delta Math Word Problem Solver Percentages
• Delta Math Word Problem Solver Ratios?
• Free Math Word Problem Solver: How It Works

in t | Time to build (weeks) | weeks | 8 | 0
in d | Dev cost per week | $ | 1500 | 0
in u | Expected users in first month | users | 100 | 0
in p | Price per user per month | $ | 10 | 0
out total_cost | Total dev cost | $ | t * d | 0
out monthly_rev | Monthly revenue | $ | u * p | 0
out payback_months | Payback time | months | (t * d) / (u * p) | 1