Note: I initially wrote this post on my previous blog, July 2020. This has now been moved here.
Hey, here's the deal: you hear advice like "Just ship it" or "build the MVP" this and that.
But you also find out sooner or later why this advice keeps being put out: you always feel like you need to add one extra feature, or one extra module to your SaaS app before putting it out.
Postponing too much because of a need to "make it perfect" led to "just ship it".
If you've read enough stuff on the internet about building a SaaS business, you'll also know about the wisdom behind talking to your customers — having customer interviews.
Here's the deal: I hate customer interviews that don't work.
Or whatever that thing is called when you have to sit down with people and bug them with millions of questions about a "what-if" SaaS product you've got on your mind.
You hate it too?
Of course you do, few people really do enjoy it when it's not working.
You thought it was cool when Steve Jobs quoted Henry Ford about the horse thing ("If I had asked people what they wanted, they would have said faster horses") — it'd be wonderful if you'd just build your thing and not have to talk to people.
And most people do customer interviews wrong apparently, as the "Mom Test" book can show you. Most hackers are looking for validation for their idea instead of actually mining for gold nuggets of potential value they can build.
I did have some conversations with possible buyers and they turned out fine. But I still didn't get the confidence that what I'll build will be bought, or whether I'll waste (and have wasted, so far) my time.
I don't code so I'm paying people to do that. It's not like I can just trade my time and find out.
No, I'd lose some serious money I'd invest into development if I make something people don't want to buy... And besides, what if there was a way to "raise money" without giving out any equity? Elon Musk has done it. Tesla "raised" $450m in reservations for the Model 3, which lined up to sales of $16B+.
I thought the same could be done if I pre-sell the SaaS: the money would be "raised", because the money received is poured into development.
So I wanted to see how many people will pre-order...
1. My idea
2. Which doesn't really exist (yet)
3. Which I'm not sure if it's worth building, but if there's a bit of movement, I'll proceed with building it
And I did get a SaaS pre-order on the first day! And some after. But before I get into telling you about how I've done it and what I propose on how to pre-sell SaaS...
I can plant some of the advantages I've had for myself within this article, maybe even try to hide them (or not even putting them out at all), but you'll probably feel betrayed later on.
At the same time, I'm no Elon Musk who can start a new business (or a car model) with tons of advantages. You probably haven't heard about me — I'm just a random dude who's got a philosophy about SaaS products.
So I'll tell you from the beginning what advantages I've had before pre-selling $1,000+ of SaaS without writing a line of code — I don't want this to be a YouTuber guru video of "yOu cAn dO iT aS WeLl if you buy my ebook".
I'm just documenting how I did it, then telling you why I'm writing this post, then finally getting into how to do it.
Advantages I've had:
However, at the end of the day I'm selling something that doesn't exist yet. So whatever advantages I've got are not "unfair advantages". It's still an uphill battle.
At the end of this article I'll address my objections against these 4 advantages and how to tackle them yourself for your SaaS pre-selling campaign.
It's not a LinkedIn type of post where I stroke myself based on what I have achieved (at least not directly). It's also not the next-level, smarter way to peacock, in which I kinda virtue signal what I have achieved, but I pack it in a "I'm sharing the good! It's all about teaching! Putting the good out in the universe!"
I'll assume you're smarter than that.
I'm doing this in a kind of Jared Vennett way in which I'll lay out what I get out of this whole post in exchange for... hopefully your trust. You may not be as skeptical-about-everything and pissed-at-life as Steve Carrell's character (Mark Baum in the movie), but oh well.
I'll tell you why I'm doing this:
You know what's in it for me, since I'm saying it directly. So I'm hoping this earns your trust. No more selling after this point (except for one last time at the end which you can skip).
Now that I cleared out what I had in my favour and why I'm doing it, let's get into it.
Remember: the purpose of pre-selling SaaS is to find out whether:
The rationale is simple: if people pre-order it, despite it not existing (who does that, right?), then they'll be even more demand when the SaaS product is actually out there.
Obviously you start with a boost in terms of chances if your SaaS is made for you: if you are part of the audience. You can estimate better the points above if you’re building something for yourself (that is for another post though).
If you know how to create UI/UX mockups, create them.
If you know how to code, create a working app that strikes the balance between
If you know neither code or UI/UX, your best bet is with UI/UX mockups.
What I need to note is that what I wrote in the "if you know how to code" paragraph also applies to UI/UX mockups. I have had areas of the app I'm pre-selling where I used text to help the user imagine how that will work.
Notice the explanatory text below the "Chats" header. This is how I could launch the app in a lean way, just disclosing what this area would do, without making it working. It sucks, but it can get the idea validated for you.
Here's how I can present it though:
How do you judge whether you'll use text or whether you'll design/code an area of the app? The answer lies in the aforementioned balance you need to strike. People know what a chat is, so I didn't need to spend a lot of time to design every corner of that function.
However: are you designing a new messaging app where messages go horizontally?
That sounds unnatural, so I (the possible buyer) would need to see that visually to get an idea of why looking at messages horizontally is a better idea. If I get sold on the idea, I will pre-order the SaaS.
P.S: I suppose you can skip this step, but I don't recommend it. Unless you've got a very persuasive way with words and a lot of advantages (like the ones I noted in the beginning of the article, but like... you're Elon Musk and got a proven track record), I wouldn't skip this. If you do want to do it, I'd go about it by building a strong philosophy and a "call to arms", promising that you're going to fix a very specific problem. Assuming you do convince people, you'll have to deliver strongly: the product has to be A+. And people will have to imagine something that doesn't exist, so do be ready for a lot of refunds.
At this point, you likely have something to show (unless you went the madman route and skipped step 1).
What I'll address now is what I recommend writing in a document.
We're not building the website yet. What we're doing now is: we're preventing yourself from selling a tool (major pitfall for most SaaS creators out here), and putting you in a position to sell a fix to an expensive problem.
To make yourself more sellable.
Once you create this doc, we'll then create the website and if you follow what I'm saying, it'll go downhill from here: I promise you'll also have a page where you explain all the features, which is what every hacker wants.
The page with features is not left out. But if you start with explaining features, you'll lose sight of the problems (expensive problems, hopefully!) you're solving for your users.
And at the end of the day, what gets you MRR in your pocket is the concept of problem-solving, not feature-explaining.
To make your life easier, I suggest the following framework.
There's no need to complicate your life with words like "storytelling", "democratizing", "holistic approach" or some other words that make it look like it's magic. No, business can be as simple as "I fix problem, you pay me"
In simple terms, what you want to do first is create the context for the problem you're solving.
In practical terms: are you creating Stripe? (imagine Stripe didn't exist) — well, why? Oh, because payments are a problem in the butt. To create the context for the problem Stripe has solved, you'd go on and explain:
The purpose of this is simple: to put the reader (supposedly a person who's got the problem, you know!) in that state of mind.
Don't worry, this is not arcane dark magic stuff. And it's not manipulation either. It's there to "screen" people: if they don't have that problem, they're not your customer and they won't feel what you're saying. They will probably go away from your website.
People's problems can be roughly boiled down to:
Once you create the context for the person, they're now closer to being in the mood of knowing that problem. Once that happens...
I know it sounds Machiavellian so far but truth be told, you've been through the same process: you imagined you could do something (which your SaaS now does) and there was no proper solution.
You believed there could be a better way to organize the Universe, so you created your SaaS app that helps you do something easier.
This "press an open wound" step should be a discussion between pre-app you (the person you were before the SaaS app was created) and post-app you (the person you were after it was created). Pre-app you had the problem, but post-app you got it solved.
What did "pre-using-app you" want to hear that gave them a glimpse of hope?
Because when someone says "Doesn't the way we do it now suck?" there is a hidden implication that there is something better.
What did pre-iPod people want to hear that made them a small promise there is something better?
That's how humans are: unless there's a solution, most of the times it's easier to ignore the harsh reality. Because if you face it, you're now in a harsh reality: music players suck, we have to walk around with CD players and Walkmans and that's about it. "Great, another reason why life sucks."
So you're not going to say that unless you have a better way out.
To get practical, at this step you're saying one/a few things that promise a better way out:
I'm 100% sure that if you built this SaaS app for an audience of which you're part of (i.e. you also built it for yourself), at one point you've thought some of these sentences.
So there you are, telling the truth probably, which doesn't require you becoming a snake oil salesman.
Next to this, you'll add the fruit of the next step, step 2.3.
This step is quite simple. Pick the sentence that makes the most sense to your case and add it. After articulating and pressing on the problem, promise a better way out by saying something like:
There is a list of features to your SaaS app you can think of, if you sit down and write them. 5, 10 or 20. Before doing that, I suggest writing off the top of your head what the first features/functions of your app come up to your mind as you wrote the 2 previous steps.
Why?
Because you yourself are in that mood of "I got this problem", so it'll naturally come to you. The things that will cross your mind, in that order, will be relevant to your reader.
Remember: you know the solution, your user doesn't.
So whatever comes to your mind after writing i) the context of the problem and ii) the pressure on the wound — those will be what the user will have wanted to hear about, had they known everything like you do.
After that, make a list of all the problems your SaaS solves. They have to be problems that incur a cost to someone (could be time cost, monetary cost - anything) and not generic problems (i.e. I have less time if I do Y). You won't write a long list here probably.
Then, make a list of all the features. This is what you would've added to your website if you were falling in the trap I mentioned earlier, which is what most SaaS indie hackers do.
Now pair the few problems you've listed to this list of features. Whatever you can.
As a last step, rank those problems in the order of importance for your user. Naturally, the features that are paired with a problem will be closer to the top.
The #1 at the top of your list will be added to your promise, back at step 2.3.
That's your tangible benefit, the real, measurable, palpable benefit that's most important to your user.
Add the tangible benefit next to the promise, which will make it something like " We've fixed it: you can now accept payments with 7 lines of code."
Congrats, you just made your life a whole lot easier and now you've prevented yourself from the despair of not knowing how a website should be structured. And finally, the long-awaited step.
Here's why we've done the previous step and the plan forward:
For disclosure, here is how my two pre-order/pricing pages look like:
When it comes to pre-selling SaaS products, the only way you can get people to pre-order your SaaS product is to offer them something strong.
It sounds dumb obvious, but I'm putting it in text because there's no other way around it.
Offer them something which makes them want to get it today, assuming they've already bought into what you're selling. A strong deal. I have the following personal suggestions/proposals.
The thing is, since you don't know exactly when you're going to launch, you can't really ask people for a monthly payment — what are they even getting? To me, it seemed like the only way was to bill yearly. And this yearly bill will begin from the moment we launch.
So in practical terms, I'll edit the subscriptions in Stripe for all the pre-orders, so that they begin from the launch date.
Most SaaS companies offer a better price for yearly payments, as opposed to month-by-month payments: it helps them with cash flow and it also helps the buyer. You'll probably do that as well.
What you can do is compare the price of the pre-order to the monthly plan you'll be offering, so not adding the yearly plan at all. This way, there'll be a bigger gap (and therefore the sensation of a better deal) between the two plans. That's what I've done with the Organizer (in the previously-linked image).
However, with Synergy, I laid out all 3 plans: monthly and yearly (both of these unavailable), then the pre-order offer.
Should you skip the yearly plan or not? Which one works better? I genuinely can't know. But to choose between the two, I think it matters to take into account the profile of your users. In my case, my thinking was:
That's my take on it and I don't have a way to be sure it's actually helpful, but go with your gut. Just take your gut through the lens of looking at your audience.
I wanted to make it fair to these people, so I'm offering hassle-free refunds:
It just seems fair and putting it out eliminates another objection/roadblock that prevents someone from buying. After all, you're selling something that doesn't exist, so who can know whether they'll like it or not! Give them an easy way out.
I'm fully against life-time deals [Note: I've changed my opinion and I don't agree with my younger self, as of Sep 2021 when I'm moving this article to www.Simple.ink. This was originally written in July 2020]. SaaS is an unspoken contract:
“Pay for our product monthly, dear customer, and we’ll keep on making it better. We guarantee our promise, so feel free to stop paying if you feel like we’re not making it better”
It might be tempting to sell a life-time deal, but life-time pricing sooner or later ends up worse for both the buyer and the consumer.
The incentives are simply not aligned: once a LTD (life-time deal) sale happened, the developers' interest in this transaction plummets. Yes, in the beginning it doesn't, they feel the high of a new sale, but after 9 months at latest, they're closer to saying more and more often "I'll just skip this task, they paid for it anyway — let them be happy with what they got".
You don't want that.
And I'm saying this applies both ways: I automatically discredit a SaaS product when I see it offers life-time pricing, unless I'm ok with it being in the same shape as it is now (and also ok with it disappearing).
Life-time deals in SaaS go south sooner or later for both sides.
As a buyer, you want to support the developers not because you're nice (you don't have to be nice), but because you want the unspoken contract I've written above to keep on working.
As a creator, you don't want to put yourself in a position where you'll be resentful towards your customers. And know this for sure: you can start hating customers really fast.
Don't offer life-time deals in your preorder.
I've also offered priority customer support on the Organizer. Feel free to chip this in as well as a benefit to your SaaS pre-orders.
Alternatively (and this might not be very useful to most of you), you can offer more months for the same price — I did this in a referral program, where leaders of waterholes had a code, and the buyers brought by these leaders got more months (13 months or 14 months) for the same price. You can pitch this is as a smaller amount paid per month, but that gets complicated — people have to do math in their heads. "2 extra months for free" is easily understood.
You won't really want to pre-sell too much. I've thought of it this way: if 100 people get on my pre-order offer, that's $30,000.
$30,000 is more than enough to "raise" in a pre-order. Anything more than that can be too much. 100 looked like a right number.
I wouldn't go for more than 100 pre-orders since the risk/benefit ratio can become too high if something goes wrong. A refund on a $300 purchase is about 10 bucks. If everything goes south, that's 1 grand I'd pay out of my pocket for all refunds — not the end of the world.
Besides, this also creates scarcity for the benefit of the customer — it increases the value in the eye of the buyers.
Don't get me wrong: I hate black-hat techniques as much as the next man, but this, at most, puts urgency on the buyer to get their deal. Doesn't sound like damaging in any way to me. This, paired with the no-hassle refund policy should help you get over the possible reticence to put up that badge of "Only 100 available!"
All these steps you've done so far line up the purchase process for your pre-orders. Everything should be working, assuming people know you and they trust you.
But most people don't know you nor do they trust you. So what do we do? Aid these problems as much as possible. To do that, what you'll want to do is think of, and then address objections.
How you do that will be up to you, since you'll know your audience better than I do, but I can tell you what I did for mine.
I've explained a bit more in-depth this earlier — but seriously, do it.
Write this FAQ and as soon as a question arises from your prospective customers more than a few times, add that answer (along with the question) in the FAQ. Feel free to draw inspiration from the two ways I've done it, along with the questions and the answer themselves, if you feel they help.
If you've got a public persona, it's time to make use of it.
If you don't, start building that now.
What I mean by a public persona is essentially anything you've done publicly in the last years that can bring authenticity to who you are. Whether you've been:
— all of these can help prove the fact that you're not looking to scam folks. It's not a guarantee, yes, but at least you've got your reputation on the line.
If that's not the case, you can start building it now. How— that may be for another post.
What do you do with your public persona? It will depend on how to position your SaaS, but here are two ways:
If you know anyone else with a public persona that can vouch for you in some way, make use of the social proof. SaaS companies do that but... you can make use of that as well.
If the public persona is not strong enough, anything else you can think of — make use of it. Perhaps writing alone, if it's done for a serious period of time, contributes enough so that there won't be a need for anything else. Maybe a semi-popular open source project gets you the authenticity you need. Perhaps you wrote in a certain publication/magazine.
But regardless of what you do to make use of your public persona, the point is to just prove that you're not a random who will run away with their money.
The whole point of pre-selling your SaaS is to see if there's any demand for your product, despite it not being ready or even built. So now you've set yourself up to be open for pre-orders — it's time to get the word out there.
This step requires an essay of its own, where I go in-depth about it, but in here I'll address the big picture.
Everything I explained so far, whether I pointed it out directly or not, was meant to put you in a better position to be "lucky" or successful. Take the "address objections" step: that is an effort to de-risk your business.
What I think you could do to put yourself in a better position to succeed, when it comes to promoting your SaaS business, is to build it with a philosophy.
If you build it with a philosophy, you can write that philosophy down — and it will speak to people who share it. In a sense, this is what major political movements (healthy and unhealthy) do: they set a philosophy and then they have a "call to arms".
Take Stripe for example, since we've mentioned them earlier: their call to arms is "We're increasing the GDP of the internet" — it makes sense, it benefits the world, and it benefits them.
Take HEY.com's example — their philosophy is that email was broken and that the last time we've been excited about email was 16 years ago (email was broken and neglected). Their philosophy also states that a good email client will make you spend less time on email, freeing up your time.
I'm probably not paraphrasing their philosophy correctly, but here's what's valuable: I remember some of it. What's Gmail's philosophy? What's Outlook's?
Not only it's easier for you to build software if you have a philosophy, but it's also easier to promote it: the opinions will be more divided, but love doesn't come without hate. It's either love+hate or boringness.
To get to the practical aspect (since I'll be writing an essay of its own for this topic, at a later point):
This step also ties in with the public persona argument: do this through tweets, blog posts, videos, podcasts — whatever is within your area of do-ability. This, in turn, shows that you're serious and builds up credibility.
The information in this step is scarce and only top-level, but it should point you in the right direction, so that this guide doesn't leave you butt-naked with no clue on what to do next. I will, however, address this whole topic in a separate essay.
That's it. That's how I pre-sold my SaaS (and continue to do, at the time of writing this) and what works for me may not work for you, but it's worth putting it out.
Do let me know what worked for your SaaS pre-selling campaign! Send me an email — let's make this guide better collectively.
What comes next? EASY! Building and launching it to users.
I have two more things to say: I want to make the case against the advantages I've had, to paint a clearer picture and... of course... promote myself at the end of this article, as I promised in the beginning.
———
So let me quote the advantages I've listed earlier again:
To address them one by one:
So that was that. I guess...I pretty automated, so that I can have time for stellar customer support. And if you buy theiu'll see more writing from me.
Or pre-order them, if you're reading this early. Buy them if I've already launched them.
Or don't — maybe you hate me already. But if you don't, pre-sell stuff as well and let me know with an email, I'd love to know how you did it (I wanna learn from you you know?).
Ch Daniel is the co-founder of Simple.ink and chairman of the CH Group. Daniel is leading the development of new products of Simple.ink, as well as strategising how else the company can reach its main mission: empowering 1M+ people to build using simpler no-code tools.