Don’t Launch Your New SaaS Platform Until You Conduct These 7 Key Tests

This is a guest post by Ethan Drower, co-founder and Operating Partner of CiteMed, a Chicago-based tech startup that’s disrupting and revolutionizing the European Union Medical Device Regulation (EU MDR) process).

Saas and software-based platforms are never what they seem. To most casual observers, you simply put together a useful piece of code, make it available online, and watch the users and cash flow pour in while you sit back and collect monthly subscription fees.

However, those of us that have actually spent the time trying to build and launch software platforms know that the process looks more like this.

• Go over the budget and timeline 2x to build the prototype
• Launch said prototype with minimal fanfare
• Spend your next month fixing urgent bugs from only a handful of users
• Look with disdain at your MRR and customer retention analytics (if you even have them)
• Fix more bugs and respond to user complaints

Fortunately, these pains can be minimized, if not eliminated, by taking care to make some strategic decisions before you build and launch your software platform.

The following are some hard lessons I’ve learned in my 10+ years as a software developer and as the co-founder and Operating Partner of CiteMed. In this article, you will read some actionable tests and steps to take to ensure that your launch goes as smoothly as can be expected (just know that it won’t be smooth no matter what you do, and that’s fine).

Market Validation and Interest Test

Does anyone even want the thing you are trying to build? I would be remiss if I didn’t mention this all-too-critical step. Before you launch (and ideally before you build), you need to determine if there is sufficient interest for what you intend to build.

So how do you determine if people want your software? Try to sell it to them.

It’s really that simple — pre-sign-ups and, ideally, pre-orders are the fastest way to see if your idea hits on any customer pain points or desires. If you drive 1000 visitors of your chosen target audience to a landing page explaining your software with 0 sign-ups, then it might be time to reconsider the product or the market fit.

One of the first apps we ever built was truly exceptional. It was a completely autonomous marketplace for independent massage therapists (and other spa service contractors) to run their businesses and find new customers.

The only problem? No one really wanted to use it.

We spent months developing a finely crafted platform that simply no one was that interested in.  It was a complete flop of a launch and a lot of time and money down the drain. All of that could have been avoided if we spent a few months trying to get sign-ups BEFORE sitting down to build anything.

Rapid Deployment

How fast can your developers get new code out to customers? Now it’s time for the technical ‘tests’ you want to be passing before launching your new, beloved platform. Take a look at the loop of time and effort it takes to:

1. Receive a bug/complaint/idea
2. Get that information to your developers
3. Write a patch
4. Test that patch
5. Deploy it to users

This feedback loop is absolutely critical to the success of a young software-based application.  Your early adopter users will be fine with coming across issues and bugs, but they will NOT be fine with bugs that take weeks to correct. If you neglect the user feedback, you will find yourself with a churn rate that will make even the most seasoned VC start to tear up.

So how do we shorten the cycle as much as humanly possible? By ensuring that we have some kind of rapid deployment process in place. This can be a github/gitlab pipeline, or if you want to go even leaner, you can use a managed service like Heroku to offload all deployment concerns.

I personally recommend the latter if you’re a smaller team without much (or any) funding. Using Heroku virtually eliminates the need for deployment scripts and makes rolling back new features a one-line command.

I have run the gamut when it comes to different infrastructure and deployment processes, from complex AWS deployments (in the early days) to bare-metal installs managed with a jumbled pile of Ansible scripts.

I’ll spare the details, but here’s what I can guarantee you when it comes to deployment: if your lead developer can’t push a new fix with a one-line command, and then roll it back with another one-line command, your deployment pipeline isn’t fast enough.

So whatever solution you go with, make sure that it’s as lean as possible to ship new code to your users.

Does Your Infrastructure Scale?

What happens if your product goes viral and you 100x your daily sign-ups? Scalability is one of those things that doesn’t matter at all until it really matters. You don’t need to spend a ton of time in the early days writing a perfectly scalable code to 10 million users… but at the very least you need to be able to throw more physical resources at a surge in traffic.

Fortunately for founders today, auto-scalability is only settings toggle away on a platform like AWS or Heroku (built on AWS) or Azure. Managed cloud solutions are king here when it comes to your webapp.

Of course, throwing a ton of memory and compute power at horribly written code won’t fix your problems indefinitely, but that autoscale at the right moment might just nab your company a bigger percentage of those precious early users.

Is There a Direct Line to Your Team for User Feedback?

How easy is it for users to get in touch with you when they have a problem? When you are launching a new software platform, you want all of the feedback. Therefore, you need to make it as easy as possible for your users to tell you if there’s a problem.

Whether it’s live chat, a direct support email or ticketing system, or a Twitter account, pick your poison and put a reference link to it on every single page of your application. Ideally, help is just one click away for users, and they get a direct line to whoever has access to your development team.

Another app company I built was a perfect case study for this. Here was the situation:

The app allowed people to search for food trucks nearby, and then users could preorder and pick up right at the truck. After 1 full month in operation, we finally got around to checking out user logs and analyzing their behavior on the app.

We were shocked to see that over 35% of users abandoned their first order on the checkout view of the app and then never came back. Yikes.

Upon further investigation, we noticed that a device-specific UI bug was occurring that prevented these users from actually sending their order. Frustrated, they just closed out (and probably decided to just get in line at their food truck of choice).

Upon further reflection, we also realized that we made it damn near impossible for a user to contact us with an “in-app” problem. We just had a general email address deep on our website that people could contact us for inquiries. Of course, no user frustrated with the app even bothered.

Within the next week, we had thrown in an intercom-style live chat feature and watched the feedback pour in. We were able to identify widespread bugs and fix them in hours and days, not months.

Build a Manual QA Testing Machine

Legitimate testing of applications is a subject of great debate amongst CTOs. In my opinion, too many early-stage companies waste too much time trying to build out a massive suite of automated tests for their applications.

What you find halfway (and double your budget and timeline) is that writing accurate and automated UI tests for your app is actually more difficult than building the thing in the first place.

But you still need to be testing something. 

So I propose a solution that is less scalable, but more economical (in time and money). Simply build out a robust manual QA testing process, and hire an affordable and savvy team of offshore contractors to carry it out week in and week out.

We try to keep things as simple as possible, using a testing management app like Qase.io, and have our team run through every build before doing a new release to our customers.

No matter what tools you choose, be sure that you have some simple and affordable way to QA test the nuts and bolts of your user experience every time you release some major features.

Security and Financial Transaction Audit

This test really depends on the nature of your platform and the type of users you intend to support. The more financial or complex your application is, the more risk there is on your side to overlook some basic security issues.

If you’re building the next Angry Birds, you can probably disregard this section.

But if you’re doing some advanced integrations or payment processing, it may be worth it to pay some outside security consultants to come in and try to break your application. There are a whole host of different companies ranging in size/competency/price to choose from to do these kinds of audits.

My advice is to make a judgment call on the “risk” of your specific platform, and then pick a consultant according to that level of risk. The more risk, the more audits.

The MVP Shame Test

The classic Reid Hoffman quote says it best:

“If you are not embarrassed by the first version of your product, you’ve launched too late.”

One of the final “tests” for your new platform is how you personally feel about it. If you are thinking that it’s at least 6 or 12 months away from being “there”, then it’s probably time to get it in the hands of some users.

This is the hardest possible decision to make, and of course, it is also the most critical. It’s too easy to say “just a few more of these nice-to-have features and then we’ll get it live.”

Launching early with a barebones app that breaks on mobile browsers is 100x better than spending 6 months making things smoother for your future users. Put it out there, and implement all the previous tests to ensure that you are rapidly iterating and improving every single day.

And don’t forget to enjoy the ride. 🙂

Ethan Drower is the Co-Founder and Operating Partner of CiteMed, which is revolutionizing the European Union Medical Device Regulation (EU MDR) process. Literature Search and Review is the cornerstone of medical device companies’ Clinical Evaluation Report, and CiteMed has made this process more streamlined and optimized than ever. The CiteMed team was formed to deliver a high volume of beautifully written and formatted Literature Reviews on timelines that will enable companies to meet their EU MDR goals. CiteMed’s top goal is to help companies get their medical products to market as quickly as possible, all while maintaining state-of-the-art compliance with the European Commission regulations. A renowned business expert, Ethan educates others on the fundamentals of launching a successful software product, tips for aspiring entrepreneurs, and more. www.citemedical.com.