No-Bullshit Blueprint To Ship Your SaaS In 5 Days

This newsletter issue is brought to you by:

If you want to watch a video instead:

This issue as a condensed Twitter thread:

There are more regurgitated guides on how to build MVPs than I can count.

Some are old, others are only theoretical without any practical advice, but the majority are full of crap, which can hurt you more than help. So you have to be very careful who you listen to.

My goal here is to give you a step-by-step blueprint - my exact thinking process to build your MVP by Friday.

Yes, you can do it in 5 days if you follow this process, so you can start selling next week.

Doesn’t matter if you’re using no-code or yes-code.

The process is exactly the same.

What’s important is that you’re comfortable with your tech stack. Of course, if you don’t spend full-time on the MVP, it will take longer than 5 days.

The same is true if your product is a bit more complex, but even then you shouldn’t go over 10 days of full-time work.

What problem are you solving?

You have to know what problem you’re solving and who you’re solving it for to make this blueprint work for you. That’s the first thing I ask my clients when they reach out and that’s what I think about for my own products before even considering what to build.

But that’s not something we’re covering in this issue, so if you want me to talk about it in the future, just hit reply and let me know!

Here, we’ll go through the blueprint together while planning out my next product: landingleap.ai

I haven’t talked about it until now as I needed some time to figure out what it’s about and who it is for, so disclosing it here to you first.

Short version: it’s a no-code website builder for SaaS products. Only landing pages for product ideas in the beginning, but will potentially evolve into a full-suite martech for SaaS.

I’m building it for indie makers who launch SaaS products. In other words: I’m the ICP.

But hold on, I can already hear you asking, “Aren’t there a million of these out there? Why would you build another one?“

It’s because this market is already validated and I only need to bring one unique angle to break through. People are already used to paying for this and I can start quite small.

Don’t be afraid of overcrowded markets!

Focus on one core thing

That’s the first trick when building an MVP: find out the single core concept that you’ll build around.

A few paragraphs up you’ll notice how I mentioned my future goals for this product: an all-in-one marketing suite for SaaS. However, that’s something that will cost at least $150,000 to build!

Not only that, but it’ll take more than 1 year to launch. Ain’t nobody got time for that!

We want something we can launch in less than 2 weeks if it’s too complex for 5 days.

(In my case, I’m okay with it taking up to 1 month because I’ll be spending less than part-time on it)

So I’m starting out with just a landing page builder for SaaS products. Its goal is to help you quickly give some shape to your product ideas to test them out and see how prospects react.

I’m not going to sell you on my product here since that’s not what this newsletter issue is about, but if you’re curious, just sign up on the waitlist to learn more.

Now that I got this out of the way, let’s get back to figuring out what we can build FAST, so we could ship a working version ASAP.

Zooming in even more

Even if we focus on just a landing page builder, this can still be very complex: products like these range from minimal to infinite customization. Think what you can do in Webflow / Framer vs yep.so (which is actually the competitor that triggered me to build landingleap.ai because it isn’t up to the task).

The “less work“ route is limiting how much you can customize (which, incidentally, is actually what I need from this builder because I don’t want to think about design when testing ideas), but the trick is doing that without making it feel too rigid for those that do want to make some styling changes.

I came up with an interesting idea that stems from a trend I spotted lately: wall-of-text instead of visual-heavy pages that distract you from the message.

(I’ll actually dedicate a future newsletter issue to this wall-of-text concept, but if you want it sooner, just reply and let me know)

So the landing page builder will be made up of blocks that you can customize a little bit in a Notion-like editor, but the focus is mostly on the text. There will be a few visual-heavy blocks as well (i.e. hero and CTA).

This is much easier and faster to build! It’s also what the core of the product is about, so we can define it like this:

In case you’re not familiar with this format, it’s called a User Story in Agile Development.

I found it to be the best way to define features because you’re focusing on Who, What, and Why, which gives an enormous amount of context when thinking about what to design and develop. Of course you also want to add extra information, but those are implementation details that you can figure out later in the process.

Reinforce your core

Now that we know what our Core feature is, it’s time to think about supporting functionality without which we either wouldn’t be able to build it or our offer wouldn’t be compelling enough to get people to use the product.

Define them in the same User Story format and stick with 2 or 3 tops. If you have more than that, you’re overthinking and overdoing.

I’ll be straight with you:

So what should these 2-3 supporting features be?

In product management, we actually categorize everything in one of:

• Must-haves. The product doesn’t make sense without these.

• Performance benefits. This is what prospects will compare against what your competitors offer. Better experience here will help them choose your product over something else.

• Delighters. It’s what competitors don’t have, so users don’t expect them, but can turn a good user experience into a great one. It’s how you turn casual users into evangelists.

So our Core User Story is the must-have. There’s no landing page builder without the no-code builder itself, right?

Now we’ll focus on the other 2 categories with our supporting functionality.

By the way, I highly recommend you include a delighter! So if you need 2 performance benefits, that’s when you’ll choose the 3rd supporting feature to be a delighter.

If you can get away with 1 performance benefit, the 2nd supporting feature should be a delighter. No need to force a 3rd feature to come out in this case. Just be happy that you’ll need to do less work!

For landingleap.ai, we’ll need 2 performance benefits, unfortunately:

Normally, this wouldn’t be a simple User Story to implement, but I already have a very good starting point from a different SaaS, so it’s very little effort to add.

And the other one:

It’s something we can’t avoid because of 3 reasons:

• our domain name

• huge time saver

• competitors have it

If we can make even slight improvements when implementing these User Stories, it will already be enough of a reason to choose us over the competition. It’s really the same for your product. You don’t need to make a huge leap in your first attempt! Slightly better is more than enough.

Of course, you’ve got to work on improvements that actually matter to your ICP! Don’t just pick random performance benefits without researching unless you’re the one you’re building the product for.

But we’re also going to add this delighter into the mix:

(Yes, you can A/B test even with hundreds of visitors, no need for thousands, but that’s a topic for another time)

This is a delighter because no other no-code landing page builder for SaaS products has this functionality built-in especially at our price point.

So you have to study your competitors to come up with what your delighter is going to be. Please don’t skip this step!

Hopefully you didn’t.

Planning your product development

Alright, so now that you have your core, your performance benefit(s), and your delighter (you didn’t skip this, right?), it’s time to put together your Product Plan to guide you on your build process. You need this regardless who’s doing the build: you, an employee, or a contractor.

But I’m not talking about a formal, complicated document!

I just mean putting together the set of User Stories you’re going to work on, add details to each one and set Acceptance Criteria, estimate them (preferably with Story Points or Ideal Days), and arrange them in a Gantt Chart or Calendar to visualize your progress.

Here’s a little potential setback: you won’t get away with just the User Stories we defined earlier in the process. There is still one set of functionality that I haven’t talked about: Infrastructure features.

Think of them as the container of your SaaS where you’ll put your must-haves, performance benefits, and delighters.

Things like authentication, onboarding, and payments - they don’t help your product’s value proposition, but without them, you can’t have a business.

If you don’t already have your SaaS Factory, this part will certainly slow you down while you do the first-time setup, but for future products, it’ll be much easier to build since you’ll no longer have to deal with these Infrastructure features. You’ll go straight to what’s important for your SaaS.

You can short-circuit this by buying a done-for-you boilerplate package that has everything you need out of the box, but I encourage you to build your own SaaS Factory as you go!

Though if you’re set on buying one, there are so many of them out there, so reach out if you need help with choosing the right one for you.

This is also true if you’re going the no-code route: you can buy or create templates, plugins, recipes for workflows and automations - anything that makes your life easier.

To start, this is what you need:

• Login

• Registration

• Forgot/Reset Password

Or you can implement social authentication instead if it makes sense for your product. Generally, the easier it is for people to sign up and log in, the higher the conversion rate.

• Onboarding

• App Container

• Link to Stripe’s Billing Portal or a custom screen in your app if you’re using a different payment processor that doesn’t have something like this

• Checkout (or redirect to Stripe’s Hosted Payment Page)

And that’s it. No, I didn’t miss things like “User Profile“, “Admin CRM“, and so on. If you have them out of the box, go ahead and use them, but you don’t need them to get started. You can delete accounts manually. You can change emails manually. Basically, ignore everything that isn’t absolutely crucial!

You don’t want to waste development efforts in that direction. Better to start selling sooner!

But before you do that, I’d also include a few extra tools to help out:

• Analytics (PostHog)

• Live Chat (Crisp)

• Feedback Collection (Feedefy - I have a 10% discount code for this one if you want to use it, so just reply with “Feedefy“ and I’ll tell you how you can apply it when purchasing your subscription)

Otherwise it will be difficult to understand how you can improve your product.

For landingleap.ai, this is what my Product Backlog (i.e. the place where you collect User Stories) looks like:

Next, I’m taking them and scheduling on a Calendar (make sure you do it with your developer if you’re not going to be the one building it because setting arbitrary deadlines is pointless), but compared to the product that you may be building:

• I’ll need the equivalent of 10 days of full-time work instead of 5 (a good quality no-code editor takes time)

• I’m spreading them out over 4 weeks because I also have other commitments

MVP is not meant to be a crappy product

No matter how complex you think your SaaS is, you can distill it down to 10 days of full-time work. If it takes longer, peel the onion even further! Analyze once again and think about if you really need those User Stories for launch or you can leave them for later.

I found ways to cut down on features for 100% of the clients that reached out to me for help, so you have no excuse.

Remember to figure out what your “skateboard“ is from this famous MVP example:

Because I’m in a very competitive market, landingleap.ai is actually starting from #2 and that’s where the extra 5 days are coming from. For most other ideas that I have on my list, I can easily go with #1 and keep it within 5 days of full-time work to build the MVP.

But saying this again:

Build!

Now go on and build that SaaS you were thinking about and make sure to share your progress with me.

And if you’re having difficulties with figuring out your skateboard, reach out and tell me about your product: I’ll help you decide what to focus on.

That’s all for today. See you next week!