What to Ship Next in Your SaaS: A Framework for Solo Founders

The problem isn't lack of ideas

If you're a solo SaaS founder, the question "what should I build next?" is rarely about scarcity. You have a Notion doc with 47 feature ideas. Three users emailed you this week asking for things. You read a competitor changelog and felt that familiar twitch of "should I have shipped that?"

The problem is that every framework you've seen — RICE, ICE, MoSCoW, Kano, weighted scoring — assumes you have a product team, analytics infrastructure, and the patience to score 30 items on four dimensions. You don't. You have a weekend and a tab full of unread Stripe receipts.

This post is about a different way to decide: four questions that actually map to how solo SaaS works. No scoring spreadsheet at the end. Just clarity.

Question 1: Is this on the path to the next revenue event?

A "revenue event" is anything that moves money: a new signup, a paid upgrade, a renewal, a referral, or — for the brave — a price increase. Most features don't sit on this path. They sit near it and feel important.

Ask yourself bluntly: if I ship this, which revenue event becomes more likely or larger? If you can't name one in a sentence, the feature is probably maintenance dressed up as progress.

Examples that fail this test, but seem important:

• A dark mode toggle (unless users are actively churning over it)
• Refactoring your billing code "to make future pricing easier"
• A second integration when the first one has 12 users

Examples that pass:

• Reducing time-to-first-value during onboarding (more trials → paid)
• An export feature that's blocking three deals in your inbox
• A teams plan, if your free users keep adding "we" to their messages

You don't need RICE for this. You need to be honest about whether the feature touches the cash register.

Question 2: What does the actual evidence say?

Solo founders confuse two things constantly: signal and noise. A loud customer is not the market. A churned customer's exit interview is sometimes more about them than your product. A Reddit thread isn't a research panel.

Before you commit to a feature, list the evidence on one line each:

• Three customers in the last 30 days asked for X (signal)
• One investor said you should add X (noise, ignore)
• A competitor launched X (mostly noise, occasionally signal)
• You personally want X to exist (noise, but be honest with yourself)
• Search traffic to your docs for "how do I X" (signal)
• 40% of trials abandoned at the step where X would help (strong signal)

If the only evidence for a feature is "it would be cool," it's a side project, not a roadmap item. Move it to a different list.

Pro tip: keep a single text file called requests.md and date-stamp every customer ask. Six months in, you'll see patterns that your memory is hiding from you.

Question 3: Can you ship the smallest useful version in under two weeks?

Two weeks is the solo-founder equivalent of a "sprint." It's the longest stretch where you can hold a feature in your head, ship it, and still have momentum for the next thing. Anything longer means:

1. You're underestimating scope (likely).
2. You'll get interrupted by support, bugs, or life (certain).
3. The feature will land half-baked because you ran out of energy at week five.

The trick is identifying the smallest version that actually solves the problem. Not the MVP of the feature — the MVP of the value.

A user wants a Slack integration? The smallest useful version isn't an OAuth app with 12 event types. It's an outgoing webhook that posts to one channel. Ship that. See if anyone uses it. Then decide whether to build the full integration.

If you can't define a two-week version, the problem isn't the feature — it's that you haven't thought hard enough about what the user actually needs.

Question 4: What does this close the door on?

Every shipped feature is a permanent liability. It's code you'll maintain, a surface area you'll support, a tour stop on every demo, an item that will appear in every comparison page until you sunset it. There is no "we'll just remove it later" — your users will email you when you try.

So ask: what future am I closing the door on?

• Ship a free tier? Hard to remove without backlash.
• Add a complex automation builder? You're now competing with Zapier in users' minds.
• Add an enterprise SSO option? You've signaled you want enterprise customers, with all that implies.
• Build the feature one loud customer wants? You may have just defined your product around someone who'll churn in six months anyway.

This question isn't about avoiding decisions — it's about making them deliberately. Some doors are great to close. Just close them on purpose.

Putting it together

For every candidate feature, write four lines:

1. Revenue event: which one, and how?
2. Evidence: what's the signal, in one sentence?
3. Two-week version: what's the smallest useful slice?
4. Door closed: what future am I ruling out?

If three of the four are weak, the feature isn't ready. If all four are strong, stop reading blog posts and go build it.

The hard part: synthesis

Here's what nobody tells you. The framework is easy. The work is in gathering the inputs every week — reading support tickets, scanning churn reasons, watching where trials drop off, noticing what competitors actually shipped (not what they announced), tracking which keywords brought people in.

That synthesis layer is where solo founders quietly drown. You're context-switching between code, support, marketing, and billing, and the signal gets buried.

This is where Pulse fits in — it's an AI agent that watches your product, market, and users in the background and surfaces the patterns you'd otherwise miss between Tuesday's bug fix and Friday's customer call. Not to make decisions for you. To make sure the four questions above are answered with real evidence instead of vibes.

Either way: stop ranking 47 ideas. Start asking four questions.