Lessons learned after building a SaaS business

A brief list of lessons that i learned the hard-way when i started building my first SaaS web app.

After successfully running my previous old-school business for a couple of years, i decided it was time to move to the sexier SaaS landscape.

My first business is called Washr and is a online laundry delivery service. Despite the sexiness of the headline “Laundry Online”, there is very little online going on in there. Our customers place an order on the app and that’s pretty much the end of the online side of it. From that point on, it’s all about old-school delivery from and to the customer, fetching their dirty laundry, washing it (without shrinking it or make it pink) and rush it back within the promised 24 hour turnaround time.

Washr is definitely a fun business to run and what i really love about it is that it’s a tangible business. You have real customers, real interactions with them and despite being a service company, we have delivery trucks, drivers, laundromats and cleaning stuff working everyday to deliver that magical experience of getting your fresh laundry delivered to your door with no hassle.

But as a full-stack developer myself i just couldn’t resist the magic of a SaaS business. Unlimited scaling to any market? Expansion to all countries in the world with a snap of a finger? Quadruple your user base by just increasing online marketing? No fixed cost and 100% profits? I’m in!

And so i decided it was the right time and i started looking for an idea or a product to develop. And here i found the first important lesson:

Solve an existing problem

There is no point in reinveting the wheel and try to change the world overnight. Start small and find one simple problem to solve.

With Washr, my problem was the hassle of doing my own laundry or driving to the laundromat every week. I built it around this problem and this problem only. With my new SaaS product i set myself to find one problem and just focus on fixing that.

And that’s where i found an opportunity. With Washr things were going well, orders growing, sales growing…all looking good. But what were my customers actually thinking of my product? When i tried to gather customer feedback for Washr, i realized that there wasn’t an existing solution that would work just right for me. That was my opportunity right there!

Which brings us to the second lesson i learned:

Focus on one simple problem and make it super simple

When i started to look at all the available online tools for customer feedback i was overwhelmed by the options. Surveys tools, Newsletter tools, phone tools? There were so many different ways to solve my problem.

Some solutions were not just scalable like phoning each of your clients. Setting up a whole Survey Monkey survey also seemed like an overkill since i just wanted to ask if they were happy or not with the service. So many different options to solve one simple, yet key problem: understanding what your customers think of your product/service.

So i decided to come up with my own solution to the problem. That’s when Downright.io business model was created: send the customer a simple email asking to rate the service from zero to ten and then asking them why they chose that with an open-ended question.

So that was it, i spent some time refining the user flow on paper sketches and i was ready to write the first line of code.

That’s where i learned lesson three…

Pareto’s Principle — The 80–20 Rule

So i opened SublimedText, created a new RubyOnRails project and started prototyping the whole app. After just 10 hours of coding (thanks WakaTime) i had a working prototype that was able to let me import customers, send them the survey email and show their responses in a dashboard.

BOOM! That was it! I felt the excitement running through my veins. I quickly calculated how much money I could make by charging a mere $10 a month subscription fee. I closed my eyes and envisioned thousands and thousands of users signing up to use my brand new app, imagined the cash piling in my bank account. I couldn’t resist but going to the Ferrari online car configurator and played with the paint color and rim options for a while.

And then it hit me…

The app was not ready at all. Actually it was not even an app. It was some few hundreds lines of code that barely worked. Everything was missing. Damn i didn’t even have a name or a logo!

The 80/20 rule was looking at me with a grim. Despite working for just 20% of my time and achieving what felt like 80% of the finished app, the remaining 20% took 80% of all of my working time.

Looking back, it actually took me well more than 80% of my working time to go from barely working to production ready. No matter what project you will try do to, it will roughly take 20% of your time to achieve the first 80% of it. However it will take a massive 80% of your total time to complete the 20% of remaining.

Most of that bad “80%” time was spent doing Content (homepage texts and design, SEO texts, privacy policy and terms), Design (improving the UI of a webapp can be a tedious job, especially if your background is development) and general features development. Without all of these, the app won’t be usable or marketable at all. You need 100% of the app, so make sure you are prepared to spend most of your effort in fine-tuning everything.

Design Thinking is quite something

When i had to find a name and a logo for my app, i hoped to come up with some nice idea myself. I was planning to quickly find a name, come up with a nice flat-design icon for it and quickly move on.

But I couldn’t…

After trying to come up with dozens of idiotic names I gave up. I got in touch with a friend of mine which has always advocated the benefits of Design Thinking. After just a couple of weeks of time and full freedom, he came back to me with great names idea and already some amazing logo proposals.

He did that by taking a step back, looking at the business idea, writing down all the keywords and basically really doing some thinking by looking at the bigger picture, rather then just trying to come up with a name.

As a way of getting quickly feedback and go straight to the point, he suggested the name Downright. The logo is indeed a “Down” and “Right” arrow combined. I was sold as soon as i saw his proposal!

Give your app a name and a logo as soon as possible

By giving your new idea a name and a logo you immediately feel more connected with it. For me having a name and a beautiful logo that i loved was a real game changer. A great feeling is when your friends name your app using its name. It really signal the transition from idea to reality.

Don’t waste time making things scalable

This is something that i haven’t learned myself, but that i actually got by reading articles here on Medium.

The typical developer mistake is to focus a lot on scalability:

“What if we have 10,000 users connected at the same time?”

Well, that would be a great problem to have, let me tell you! Don’t waste your time building things ready for thousands of users when you don’t even have your first customer.

This is something that you probably have heard already, everybody talks about it. The MVP idea from “The Lean Startup” book is a great example.

When you are building an online SaaS business, coding is the most time consiming tasks that you have. Make sure that you and your developers are focusing on what really matters and not wasting time on crazy optimization that might be needed 2 years down the line.

As a sole developer/founder it is quite intuitive to understand what feature matters most and where to focus. However, if you are hiring a developer with not much of a business mind , it might get difficult for him to justify shipping code that isn’t fully optimized or that “just works”.

Whether you are coding it yourself or outsourcing it, you need to make sure that your coding effort are focused on those few features that you really need and nothing else.

So these are few of the lessons that i learned while building my first SaaS business. Do you think they are useful? Have you learned other interesting lessons yourself? Let me know in the comments!

PS: I am also planning on publishing a Part II of this article focusing the lesson that i learned after running (and not building) Downright.

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.