One year ago, I founded a software-as-a-service (SaaS) start-up called MealPro App. Today, we have a functioning minimum viable product (MVP), nearly 4500 users, and 10 11 paying customers including a few health and wellness influencers.
We’re not yet profitable – more money goes in than comes out – and there’s no guarantee it ever will be, but it feels like we’re on the right track.
In this article, I’ll share how I got here, and the seven lessons I’ve learned as a first-time SaaS start-up founder. Starting with…
For as long as I can remember, I’ve wanted to start a start-up. I'm always trying to think of the next big idea to make my millions. This led to a lot of failed side projects, money down the drain, and sleepless nights.
But there are two ideas that showed real promise. One was the MealPro App and the other was meal planning for bodybuilders. What did they have in common?
They weren’t strictly my idea. Rather, I stumbled upon them whilst exploring other things.
Take MealPro App.
I built a meal planning app without code (using Bubble.io) as a side project in between consulting work. It's not something many people have done. And wrote an article about it.
I started getting messages from coaches and creators in the health and wellness space asking if I could build them an app just like it is to use with their communities.
The idea of building meal planning apps for other people (i.e. business-to-business) never crossed my mind. But clearly, there was something there.
Lesson: trying to dream up ideas only led to frustration. The magic happened when I stopped trying to force it and started solving problems, plus a bit of luck. (This idea is summarized in one of my favorite articles: You don’t have to be a f****** entrepreneur!)
At this point, I had several people asking me to build them a meal planning app, so I began sending out quotes.
$10k (USD) per app might seem reasonable to a software person but it became clear that the bloggers and health coaches I was speaking to weren’t comfortable paying this much.
I tried removing the features and getting the price down but still, no one took me up on the offer. I figured it wasn’t meant to be.
Then, one evening I was listening to a Tim Ferriss podcast (#397) with Andy Rachleff (who coined the term product-market fit). At around 27 minutes, Andy Rachleff said:
“If you fix the market, and pivot the product, then you have no advantage because your original insight has gone… You have to try to find a different market or a different business model to enable people to buy your product.”
The lightbulb went off.
Selling custom apps wasn’t going to work. It was too expensive for people. But they are used to paying for software subscriptions… This is a software-as-a-service (SaaS) product.
This is the model we’ve used since.
Lesson: I always thought of pivoting as changing the product. But as Andy Rachleff says, if you do this, you lose your advantage. Sometimes you need a different business model or market.
Despite having eager customers, I wasn’t ready to give up my cushy freelance lifestyle for something that might not pan out.
But I also couldn’t ignore the urge. So, I tried to disprove the idea.
First, could I build it on a limited budget? Bearing in mind I don’t code and would likely hire someone. For this, I sounded out the technical challenges with a developer I knew (his name is Ken, he’s great). In short, nothing seemed beyond the realms of possibility.
Second, were people willing to pay for it? I’d not yet tested the white-label / SaaS model with potential customers. This bit was harder to test. Here’s what I did:
I gathered all my notes from my conversations with potential customers (when we were discussing custom apps) and paid a freelance copywriter and designer on Upwork to create a coming soon page with app mock-ups and an email opt-in. It cost about $1000 in total.
My sister then helped me set up a basic Facebook Ads campaign, aimed at people like the ones I’d spoken to. I spent about $300 on ad clicks.
The results?
I got nearly 100 sign-ups (form submissions), with the page converting at over 25%. Encouraging. But I didn’t stop there.
I emailed everyone to ask why they signed up and what features they’d like to see. After some back-and-forth and several Zoom calls, I then sent an early-bird offer (50% off a year’s subscription) to anyone who signed up before launch.
Two people signed up!
So, rather than disproving the idea, I’d managed to pre-sell it.
Lesson: the extra time spent testing the idea BEFORE building was invaluable. It gave me the confidence to invest more into the project and, because I now have two early-bird customers, it made the building process much easier (see below).
I’d managed to pre-sell my start-up idea to two customers. But it was still just an idea. Rather than guessing what they wanted, I treated it like a custom project and asked them.
Before a line of code was written, I spent hours on Zoom calls asking about what they do now, what works and what doesn’t, and more. Trying to understand their goals and pains.
As it turned out, their core needs were similar enough that I felt I could solve them with one product, but with enough differences to require customization options that future customers would also benefit from – ideal.
Then I created mock-ups for key screens, with the help of a UI/UX designer I found on Upwork (her name is Anna, she’s great too). I reviewed them with both customers.
This process effectively formed the scope of the first version and we began writing code.
All of this meant very little guesswork on my part and two very happy customers.
Lesson: the hard part wasn’t building the product, it was finding people who really wanted it and were willing to tell me how to build it. Once I had that, the building was easy.
Contrary to what I said above – I didn’t just ask customers what they wanted and build that. I had to dig deeper to understand why they wanted it and design a solution around that, which often turned out to be a little different.
For example, most nutrition and meal planning tools are designed for dieticians and nutritionists, who provide coaching on a one-on-one basis. Meal plans are highly structured with three to five meals every day. And that’s what our customers were used to using.
So, naturally, they wanted a meal planner split by day (day one, day two… day n).
However, following our in-depth conversations – and my experience – I understood that most of our customer’s customers value flexibility over rigid plans. The top-rated recipe apps in the App and Play Stores, for example, have simple recipe lists, not day-by-day schedules.
To test my theory, I created two prototypes (using Marvel): a meal planner split by days and a meal planner with a simple list of recipes. We then shared a 30-second video comparison in one of the customer’s Facebook groups and asked for votes.
The result?
More than twice the number of people voted for the simple list of recipes, plus we got a ton of comments explaining why.
My theory was proven correct, and the customer was convinced (their actual response was “OMG!! Everyone wants option 2”).
Lesson: a good starting point was asking customers what they wanted but I had to dig deeper to understand why they wanted it, and then design for that. When I wasn’t sure, I tried to test it and make an educated guess (which didn’t always turn out to be correct, I might add).
In the first 12 months, I didn’t invest much into marketing (time or money) relative to product development. It shows in the website traffic. Despite this, getting to our first 10 customers didn’t feel that hard. Compared to my previous ventures, at least.
My hypothesis is two-fold…
Firstly, the idea was born out of a customer telling me about a gap in the market. So, when we created a website and some content, we ranked on page one in Google for a few low volumes but highly relevant search terms. There literally wasn’t much direct competition.
Secondly, I’d spent considerable time on-boarding early customers (and still do) meaning they were often willing to recommend us – bloggers have blogger friends, and so on.
Most of our early customers came through one of these avenues.
Lesson: focussing on an underserved need helped me to get found online. Supporting existing customers proved a valuable way to attract new customers through referrals.
Being a solo founder is tough – every decision weighs heavily on my shoulders and, frankly, it can get pretty lonely. Especially through the three lockdowns.
But I don’t think I’d change it.
The fact that I’m on the hook for every decision also means that I don’t need to consult with anyone (unless I want to), so things can move a lot quicker.
And what I lose in not having a co-founder that my amazing freelance team has made up for.
There’s even evidence to suggest that solo founders are as likely to succeed as co-founders, again with the right team in place, which is reassuring.
Lesson: I found I didn’t need a co-founder. There are upsides to going solo, like being able to make snap decisions. The key was being able to hire good people.
I still have doubts every week – am I building the right thing. Is this the best use of my time and money (MealPro App is still funded through my consulting work), and the list goes on?
But then someone requests a demo, or I get a nice message from a customer, and I remember why I started on this journey in the first place.
As I write this, I don’t know how this will turn out but I’m learning a lot, and the software seems to be making a small but positive impact.
So, let’s see what the next 12 months bring!