I've shipped Lucuma, PostLift, SEN Letters UK, dunlin Scout and dunlin Radar, with Graft'd in beta. Some launched too early. Some I held back too long. None of them shipped perfect.
When you're building solo, there's no product manager to tell you it's ready. No team meeting to reach consensus. Just you, a Notion board, and the nagging question: is this actually done?
I've had to develop my own framework for when to ship SaaS products. Here's how I decide.
The Minimum Viable Truth Test
Most advice tells you to ship the minimum viable product. I agree. But "minimum" and "viable" mean different things when you're bootstrapping versus raising venture capital.
I run a simple test. I write out the core promise of the product in one sentence. Then I use the alpha build myself for a week. If I can honestly say the product delivers on that one sentence, it's viable.
When I built Lucuma, the promise was: "Screen CVs faster using AI." The first version had no team features, no API, no advanced filters. But it screened CVs using AI and it was faster than doing it manually. That was enough.
When to ship SaaS comes down to whether the core promise works. Not whether every possible feature is built.
The "Would I Pay For This?" Question
I ask myself: if I wasn't the builder, would I pay for this right now?
Not "would I pay for the vision of what this could become." Would I pay for what exists today.
With PostLift, I shipped when I'd have happily paid for what was on the screen. It generated LinkedIn posts, it saved me 20 minutes per post, and the output was good enough that I used it myself. That's a yes.
With dunlin Scout, I held back an extra month because the search results were inconsistent. I wouldn't have paid for inconsistent data. Neither would anyone else.
This question cuts through founder optimism. You know when you're lying to yourself.
The Pain Relief Timeline
I track how long it takes the product to relieve the pain it's meant to solve.
If someone signs up to your SaaS and feels relief in under five minutes, you can ship earlier. If it takes them two hours to feel value, you need more polish first.
Lucuma delivers value in under three minutes. Upload CVs, get a shortlist. Fast pain relief means I could ship with fewer features.
SEN Letters UK took longer. Parents needed to input case details, review the letter, and understand how to use it in their process. I added video tutorials and better onboarding before launch because the pain relief timeline was longer.
When to ship SaaS depends partly on how quickly users feel the benefit.
The Support Load Test
I imagine ten strangers signing up tomorrow. How many support emails would I get? What would they ask?
If the answer is "dozens of confused emails about basic flows", the product isn't ready.
I don't need zero support emails. I need the support emails to be about edge cases and specific use cases, not about understanding what the product does or how to complete core actions.
Before launching dunlin Radar, I gave beta access to three brokers. Two of them emailed me asking what they were supposed to do after logging in. That told me the onboarding needed work. I added a product tour and example searches. The next three testers didn't ask.
Good products still generate support emails. Unready products generate confusion.
The Embarrassment Threshold
Here's the truth: you'll be slightly embarrassed by your first version no matter when you ship. The question is whether you're embarrassed by missing features or by broken core functionality.
I can live with embarrassment over a missing feature. A user asking "does this integrate with X?" is fine. I note it, add it to the roadmap, and ship it later.
I can't live with embarrassment over the main thing not working. If the core flow breaks, or the results are wrong, or the value proposition doesn't land, that's not "iterate in public." That's shipping something broken.
When I look at the build and think "I wish this had more features but I'm proud of what it does", that's the embarrassment threshold. Ship it.
When I think "I hope no one finds this bug" or "I hope they don't try that flow", it's not ready.
The Revenue Readiness Check
Can someone pay you today and get value today?
I don't ship until payment works and the product delivers value immediately after payment.
It sounds basic, but I've seen founders launch with "coming soon" pricing pages or broken Stripe integrations. That's not a launch. That's a landing page with a waitlist.
When to ship SaaS is when the commercial loop closes. Money in, value out, user happy.
What I've Learned Shipping Products Solo
The products I shipped too early were missing core functionality. Lucuma's first version couldn't handle bulk uploads properly. I spent the first week firefighting that instead of marketing.
The products I held too long were waiting for features that didn't matter yet. I delayed PostLift by two weeks building scheduling that no one asked for in beta.
The right time to ship is when the core promise is true, the pain relief is fast, and you're not embarrassed by what the product does. Everything else is iteration.
I've never regretted shipping a product that worked but lacked features. I've often regretted holding back a working product to add things that could've waited.
How This Applies to Your Build
You don't need my exact framework. But you do need your own answer to "when is this ready?"
Write down your product's core promise. Use it yourself. Ask if you'd pay for it. Imagine the support emails. Check your embarrassment level.
Then ship it.
The biggest risk isn't shipping too early. It's holding back a working product because you're chasing a vision of completeness that doesn't exist.
Every product I've built solo shipped incomplete, and every one got better once real users touched it.
Decide what ready means for you. Then trust that decision.
If you're building something and want to talk through when to ship, email hello@marvanova.com. I'm happy to share what worked and what didn't.