Scaling SaaS for CEOs

Learn how to scale your SaaS product,

avoid common pitfalls and build a sustainable
development process
Introduction 4

Scaling SaaS 6

Getting Started: Best Practices 9

• How Could Have Your Product Idea Gone Wrong? 9

• Did You Go All in based only on Assumptions? 10

• Did You Talk with Consumers? 10

• The #1 Reason Products Fail 12

• Other Dangerous Misconceptions 12

• Don’t Assume – Test! 14

• Go Fast and Lean 14

• Best Practices Overview 16

Working with Your MVP 18

• You’ve Got Your MVP - Now What? 18

• Overdoing the Free Trial - What Spotify Gets Right, 19

Others Get Wrong

• Why Users Don’t Upgrade 20

• Scaling Your SaaS Product Begins at the Beginning 21

• Establishing a Feedback Loop 21

• Beware the Pitfalls of the Feedback Loop 22

• Don’t Give up on Your MVP Too Early 23

Choosing the Right Technologies and Processes 25

• Is Your Code Quality Good Enough? 25
• How Will You Handle Testing? 25

• Which Programming Language to Use? And Only One? 26

Building Your Development Team 29

• How to Scale a Lean Development Team? 29

• The Perfect Team for Your Development Game 30

• How Much Do You Know About Outsourcing? 36

• How to Choose Remote In-Sourcing Partners Wisely? 37

Working with the Perfect Team 40

• What You Should Be Looking for in the Perfect SaaS
Development Team 40

Fixing Existing Issues 49

• Scaling Your Existing SaaS MVP 49

Recap 50

Are You Ready to Scale? 51

Introduction

What you will find in this ebook is a comprehensive step-by-step guide

on how to build your development team, scale your SaaS product and
avoid mistakes commonly made by product owners. You will find tips
on how to get started, what strategies to use along the way and what
skill set you’re going to need to make your product successful.

At Netguru, we have been helping companies build and scale their

SaaS products for over 8 years. We’ve learned many lessons along
the way, which we feel are valuable to everybody working on scaling
their software. Whether you’re just starting out or getting ready to
improve your existing product, these lessons are for you.

Here are some of the most important questions we answer in this

ebook:

1. What is the #1 reason products fail?

2. What are the major pitfalls I should avoid?

3. What skills will my team need to avoid failure?

4. How to pick the best people to work on my project?

5. What information do I need to scale my product successfully?

6. How can my users help me in this process?

7. What are the best practices for scaling SaaS and how to implement
them?

Introduction 4
Enjoy your read and make sure to let us know if you have any thoughts
about what we’ve written.

Editors: Aleksandra Prejs, Olga Trąd

Authors: Aleksandra Prejs, Olga Trąd, Adam Nowak,

John Waldron, Marek Talarczyk, Radek Zaleski,

Design: Maciej Tomczyk

Scaling SaaS

SaaS (Software as a Service) is a wonderful thing. Programmes exist

in a permanent state of beta, which, far from being a bad thing, sim-
ply means that users of the software can expect an almost constant
stream of updates and upgrades – all included within the same monthly
(or annual) fee – for as long as they are customers of the product.
It certainly beats licensing models, where expensive upgrades would
have to be forked out every couple of years – or not, if it was simply
beyond the SME’s price range.

Yes, SaaS is most definitely the future. There are many technical-
ly-minded entrepreneurs out there who are now focussing their cre-
ative energies on coming up with ideas that embrace this model, with
big ideas about how many people are going to benefit from their great
new products, and the thousands (or millions!) of users who are going
to sign up.

Building a minimum viable product (MVP) and getting it into the

hands of your customers is no easy feat. Once that first iteration is out
there, you feel a sense of relief.

But the work isn’t over yet, and many CEOs quickly discover that
scaling an MVP is much easier in theory than in practice.

Scaling SaaS 6
In this guide, you will learn about the common pitfalls that
lead to a stalled product and the steps you can take to set
your company up for success.
Getting Started:
Best Practices
Scaling Saas 8
Getting Started: Best Practices

How Could Have Your Product Idea Gone Wrong?

All great products start with an idea. So do all failed products.

And both take a journey that looks something like this.

Your organization came up with a brilliant product idea and built

a minimum viable product as proof of concept. The road to building
the MVP was long and arduous, paved with innumerable man hours
and plenty of lively conversations, debates and arguments. But the
end result has been released to users, and now the plan is to build the
full-scale product.

Seems simple enough, right? But the process is fragile, and many
businesses fail to reach their objective of a mature, stable product.

There are a number of factors that contribute to the success or fail-

ure of scaling an MVP, but many struggles can be traced back to the
process of developing that first iteration of your product.

Getting Started: Best Practices 9

Did You Go All in based only on Assumptions?

Most companies make assumptions when building a new product.

They assume they know what their customers want. They assume
they know how the design should work. They assume which marketing
strategies will resonate, what architecture will be the most effective
and how to monetize the product for maximum profit. And they assume
that their MVP will very closely resemble the end product.

Unless you have a psychic on staff, there is simply no way to make

correct assumptions across the board.

The only way to find out if your assumptions are correct is to

get something in front of users as quickly as you can and get
their feedback. But be aware, this will lead you back to the
drawing board 99.9% of the time, so you must include this
work and this time in your overall plan.

Did You Talk with Consumers?

We asked experts about other important things to consider while

developing a SaaS product. Here is what they shared:

Getting Started: Best Practices 10

• take the user’s perspective into consideration and constantly talk
with customers;

• think about future growth and how the application will work
when used by a 100 times more users;

• switch to a growth mindset when you are flexible you can embrace
constant changes and new iterations, bugs in the code won’t stop
you;

• remember that not all SaaS products are the same, because many
aspects of the business depend on the market companies are trying
to address. That’s why defining value propositions, and having
a clear market fit is so essential.

Treat your startup as a startup, not a full-grown business. You’ll get

to that point later. Rome wasn’t build in a day.

“Understand your customers. Become your own customer.”

Michał Sadowski, CEO, Brand24

Getting Started: Best Practices 11

The #1 Reason Products Fail

In a study of over 100 startup companies, CB Insights found that

the number one cause of startup failure was the lack of market
demand. Nearly half - 42% - of those startups failed because their
products simply had no customers. What’s more, nearly all of the failed
products were months into development before anyone realized their
work was futile and their time and dollars wasted.

Other Dangerous Misconceptions

Product owners can become too involved in their product, which

leads to personal feelings getting in the way of logical thought. Make
sure you don’t fall prey to one of the two most common mindsets and
protect your product from their consequences.

I know what is good for my product

No, you don’t; your clients do. Of course you’re the author of the core
idea and you’re responsible for its development, but at the end of the
day you’re not your client. Every bit of functionality you decide to
add to your product should be based on the suggestions of your
customers rather than on your own whims.

Solution:   Become your own customer and use your product on a daily
basis — be your own harshest, least forgiving critic. At the same time,

Getting Started: Best Practices 12

show people what they stand to gain from using your product — this
may encourage them to give it a shot, too. Never underestimate a good
user onboarding process.

My product has to be perfect in every detail

The truth is, your product will never be perfect because “perfection”
is purely subjective. Some people might call it perfect, while others
will merely find it useful and others will think it sucks big time. You
just have to face the reality that your product will trigger a lot of
different opinions and that’s totally normal.

The product must be good enough and delivered fast,

then, when you have traction, you can focus on details

Paweł Kucharski, Sotrender

Solution:   Again, specify the must-have features that are absolutely

obligatory for your MVP. When you build it and put it on the market,
you can hire either internal or external developers and fine tune
the details.

Getting Started: Best Practices 13

Don’t Assume – Test!

Testing assumptions should not be a costly endeavor.

Ask yourself, “What is the smallest experiment we can run to test
this assumption?”

The answer doesn’t have to be expensive or time-consuming. You can

use things like surveys and small-scale app testing.

But you can also do creative, micro-experiments that can help you
gauge interest.

For example, say you are considering building a mobile app. To

find out if your customer base would be interested in this, place
a button on every page of your site to download the mobile version.
On the landing page, tell interested users they will be notified as soon
as the mobile product is available if they provide their email address.

Through the clicks and conversions, you can tell whether or not your
customer base would actually be interested in a mobile product, and
you’ve got simple, accurate market research to work with.

Go Fast and Lean

Your advantage is that you’re introducing something new to the

market. Use it.

Getting Started: Best Practices 14

 First, verify if the core value of your product is in the
technology or the business process. If you get this wrong,
you will most probably fail. Once you define where
the value lies - focus on fast iterations basedon closed
customer feedback loops.

Marcin Szeląg, Innovation Nest

The majority of our experts (almost 90% of participants) believe that

the crux for developing a SaaS product is speed of development and
the ability to reach market as soon as possible. Ship it and ship it fast.

Take small steps, don’t plan too much, observe, measure

your KPIs and adapt your strategy

Paweł Kucharski, CTO at Sotrender.

It’s impossible to predict everything, so don’t try. Instead, prepare for

introducing changes fast and never stop asking your customers about
their opinions. The good news is you don’t have to get everything
right with the first iteration.

Getting Started: Best Practices 15

Best Practices Overview

First of all, relax. Make a cheat sheet (you can just copy the table
of contents from this ebook) and don’t try to control all of the chaos.
You will have to let the flow carry you a little bit - the important part
is observing and learning fast.

Don’t get too attached to your ideas and make sure you have a solid
process for developing your product. Collect feedback and don’t be
afraid of working on new iterations. Talk to real consumers to make
sure you’re filling a real market need. Be proud of what you’re building,
but also careful - you’re not always right and your product won’t be
completely flawless. Test, iterate, test, iterate, test - you get the idea.
Vigilance, staying open to constructive criticism and real world
data will help you quite a bit, now and during future stages of
your product’s development.
Working with
Your MVP
Working with Your MVP

You’ve Got Your MVP - Now What?

But what if you already have an MVP? It’s built, your customers seem
happy, but momentum has stalled. First, it helps to examine some
of the reasons why products lose traction. While every situation
is unique, most stalled products can be traced to one or more factors:

• A breakdown in the feedback loop between sales, marketing and

the product team.

• Growing revenue without growing profit, limiting the cash flow

that can be reinvested in the product.

• A vicious cycle of technical debt.*

• A strong product that is not supported by the right marketing

messages.

• Strong marketing messages that are not supported by the reality

of the product.

• An inability to translate customer needs into new, usable features.

• A visionary CEO who gets mired down managing product details.

• A product team that is not equipped to manage the next iteration

of the product or see it through to the final stages.

Working with Your MVP 18

Tracing your lost momentum to its root cause or causes will help you
develop a strategy for moving forward.

*What is “Technical Debt?”

Technical debt is a phenomenon that occurs when a product is developed

using code that is easy to implement in the short run, rather than opting
for the best long-term solution. This creates weeks or even months of extra
development work and can lead to burnout, disengagement of the team,
low morale, lost revenues and a host of other non-technical issues within
the team and the organization as a whole.

Overdoing the Free Trial - What Spotify Gets Right,

Others Get Wrong

There are many different freemium models. Some offer a free trial that
expires after a certain amount of time. Others allow the user to access
basic features for free, and then make them pay for the upgrade (the
model adopted by Spotify).

What a lot of startups get wrong is offering an over-generous free

plan. It’s easy to see why this happens – the startup is so excited about
its product that it blindly believes that once people try it they will
be just as excited and won’t be able to hand over their money quick

Working with Your MVP 19

enough. But the reality is that things don’t often work out like that
– unfortunately we can’t all be as big as Spotify, and now that we’ve
got it, we don’t really need another one.

Why Users Don’t Upgrade

There are a number of reasons:

• The free plan doesn’t convince users that they actually need the
product in their lives.

• The free plan is adequate for most users – upgrading, therefore,

seems like a waste of money.

• The onboarding process isn’t user-friendly, thusly failing to convert.

• The pricing isn’t planned thoroughly enough – that is to say that

the focus can often be too heavily honed on creating new users,
rather than on converting freemium users into paying customers.

You might have already introduced a free trial of your product and
found that users aren’t upgrading. If so, try to identify the specific
cause of this situation and remove it. It might require some testing,
a lot of feedback and a few iterations, but you’ll get there eventually.
You might also consider giving up on the free trial and using another
business model.

Working with Your MVP 20

Scaling Your SaaS Product Begins at the Beginning

If you want to achieve success with your product, it all starts with
pre-planning. Remember, most new products fail because of low
or no market demand.

Test your idea by thinking like a marketer:

• Research similar products on the market.

• Go out and ask target customers if they see a need for

such a product.

• Investigate the problems that your customers are actually having.

• Create short surveys.

• Create a simple experiment to test assumptions, like a download

box on your website.

Establishing a Feedback Loop

When attempting to scale a product, an effective feedback loop is of the

utmost importance. There must be ongoing communication between
sales, marketing and the product team to ensure:

Working with Your MVP 21

• Customer needs can be addressed through the product.

• Proper messages can be developed to attract and retain customers.

• The features that are developed actually benefit the application/

product itself and will lead to more sales.

This communication ensures that the product is addressing the needs

of your market.

Beware the Pitfalls of the Feedback Loop

Open communication is essential, but teams must beware the

sales trap.

Salespeople  are under  intense pressure to close deals and keep cus-
tomers on the books. Their intentions are good, but they sometimes
promise specific features for specific customers in order to get the sale.

The product team must have the ability and the fortitude
to push back when a feature will provide a short-term gain
(a sale) at the risk of damaging the user experience or the
product itself over the long term.

Working with Your MVP 22

Don’t Give up on Your MVP Too Early

It’s only natural that you don’t achieve success in the first five min-
utes after launching your product. Go through the list of reasons for
why your product might be losing momentum and try to identify the
root cause of your problem. If you’re using the freemium model, take
a critical look at what you’re offering to your customers and get their
perspective on it. Adjust your strategy accordingly if there’s need.

Always look for data that might help you - data about other products
included. If nothing else, it will provide inspiration. And finally, check
your feedback loop - it is necessary, but remain aware of its dangers.
Finally, remember that your product is unique. You might be the only
one capable of discovering its problems, as you know it like no one
else does.

Working with Your MVP 23

Choosing the Right
Technologies and
Processes
Choosing the Right Technologies
and Processes
Is Your Code Quality Good Enough?

SaaS is a very specific type of IT product which requires expert

knowledge from whomever is behind its development, as well as
special qualities in the workflow. Whilst it’s most certainly true
that the success or failure of your project won’t rest entirely on
how well-built your software is (SaaS means permanent beta,
remember – which means you will always be able to update and
improve), it nonetheless needs to be pretty much robust and
bug-free if people are going to actually adopt and use this thing.

In many ways, so long as your SaaS is solving a genuine problem, and

your vision is near enough met during the build, then you will have
the basis for a very successful product. However, people don’t buy into
a basic solution – i.e. if you want to be successful, then you’re probably
going to need stronger coding skills than what you can acquire from
reading a few blogs, books, or taking an online crash course.

How Will You Handle Testing?

One fundamental of building any software is of course extensive

testing. Many development houses these days go in for an Agile
development approach, where multiple testing is conducted

Choosing the Right Technologies and Processes 25

within each iteration of the build. This is indeed an extremely
effective way of building software, for it means that various addi-
tional functionalities can be added to the software product in rela-
tively short time frames. But how and where are you going to test
all of these mini-updates that you build and release? You will need
to know how to deal with bugs that you find within each iteration,
and doing all of this alone is not simple.

Which Programming Language to Use? And Only One?

In all likelihood, when you begin to develop your SaaS product you
will be able to rely on just one programming language and one frame-
work to begin with. And that might be ok for a while – and of course
you might not have any other choice if you’re only versed in a single
language. But, what happens if it turns out that you need to learn
more languages to achieve what you want for your product? Does
the whole project get put on hold whilst you take yourself back to
school to get to grips with code that is completely new to you? If so,
then surely you’re going to need to build a few basic programmes
first whilst you’re learning, then gradually work your way up to more
advanced constructions. How long’s that going to take? Six months?
A year? Longer?

Quite possibly.

Choosing the Right Technologies and Processes 26

The key takeaway is that there is no silver bullet. What you
want your product to do will probably be achievable in many
different languages – but do you have the knowledge to make
the right choice, and the skills to move from one technology
to another should the need arise?

Choosing the Right Technologies and Processes 27

Building Your
Development Team
Building Your Development Team

How to Scale a Lean Development Team?

Technical debt is one of the most common reasons why an MVP

stalls, and it is often the result of a lean development team. There
is nothing wrong with working lean, after all, it keeps costs in line
and gets you where you want to go. But when you need to scale up
you need more developers, often with different skill sets than those
required to create the first iteration of your product.

This can be a significant hurdle to overcome. Hiring new develop-

ers requires  capital.  Not only do you have  to spend the money
to attract developers, but you have to pay them market value  and
offer competitive benefits.

Hiring contractors and freelancers is an option, but it’s risky.

Working with a third-party team is a much more effective option for

your wallet and for mitigating risk. But only if you approach it the
right way.

If you want to create a team that will develop and successfully scale
your product, imagine the following situation. You’re a sport team
coach and your task is to draft a team of players that will guarantee
victory in the championship. What you need is a star that will lead

Building Your Development Team 29

your whole team and a ball handler guy who will turn your idea for
the game into a game plan. You will also need a glue guy who will
pass the ball smoothly and dominating centers who will score points.
A dirty job guy may also come in handy to check whether you are
turning your strategy into life. “OK, but what does sport have in
common with product development” - you may ask. Not much. But
it was a fun way to introduce this topic.

Software development can be considered a team “sport”. You won’t

be able to develop your product all by yourself. You need a number
of people behind you who will be responsible for different areas
of your development process. Take a look who a perfect development
team would consist of and what skills they would need.

The Perfect Team for Your Development Game

Visionaire
It’s probably you,  the founder, CEO  or  CTO of the company, but
sometimes a product manager or the product owner may perform
this function.

1. Deliverables: a well written document with a product idea, initial

designs or mockups, and user stories.

2. Obligatory skills:

• Excellent communication skills

Building Your Development Team 30

 • Ability to create business models,

• Perfect understanding of the product idea, its strategic goals

and the way it will be monetised in the future,

• Outstanding grasp of the problems the product solves,

• Strong decision-making skills,

3. Nice-to-have skills:

• Ability to create an app wireframe;

Product Designer
A person who is able to turn the founder’s idea into prototypes and
designs.

1. Deliverables: a product prototype (including high-fidelity mockups,

market research, user stories and more)

2. Obligatory skills:

• Ability to solve users’ problems,

• Ability to design user-friendly interfaces,

• Good understanding of user experience,

• Eye for details, good taste,

• Ability to ask questions to users and business owners and turn

the acquired knowledge into new features of the interface,

• Ability to come up with user stories,

• Ability to conduct A/B tests of proposed solutions,

• Knowledge of web analytics necessary to optimize the product,

Building Your Development Team 31

 • Ability to create business models,

• Perfect understanding of the product idea, its strategic goals

and the way it will be monetised in the future,

• Outstanding grasp of the problems the product solves,

• Strong decision-making skills,

3. Nice-to-have skills:

• Ability to create an app wireframe;

Project Manager
A person who makes sure that the project proceeds smoothly and
keeps every team member in the communication loop. The project’s
informal leader.

1. Deliverables: division of tasks, schedule monitoring, priorities

definition.

2. Obligatory skills:

• Outstanding organisational skills,

• Ability to effectively communicate via online channels such

as e-mail and Slack,

• Knowledge of business and technology jargon,

• Knowledge of project management tools such as Jira or Pivotal

Tracker,

• Ability to monitor the budget and keep it under control,

• Ability to set the scope and choose a team for the project,

• Charisma and ability to persuade and motivate;

Building Your Development Team 32

3. Nice-to-have skills:

• Knowledge of data management tools;

Developers
Team of people responsible for turning images into a working software.

1. Deliverables: high-quality and well-documented code.

2. Obligatory skills:

• responsibility and sensibility,

• resourcefulness,

• ability to effectively communicate with both the project

manager and the client,

• good understanding of the business goals of the project,

• ability to spot technical risks within the scope of the project,

• ability to suggest compromises to work around technological

limitations,

• ability to look for already existing solutions and use them

to reduce costs and speed up the project,

• knowledge of open source projects and various development

platforms

3. Nice-to-have skills:

• Lots of experience is not always needed. What you need

instead is also the perspective of less experienced program-
mers who can have a lot of abilities unrelated to program-

Building Your Development Team 33

 ming itself, e.g. strong communication skills or the under-
standing of the client’s business.

Quality Assurance Specialist

A person whose work may seem invisible, but if a QA does not pull
his/her weight, the effect becomes striking for everyone, because

the number of bugs soars. QAs know the project better than anyone
involved in the development process. They check every single feature
multiple times and create documentation on how to test them after
next iterations

1. Deliverables: accepted or rejected tickets with detailed

explanations.

2. Obligatory skills:

• ability to describe bugs and show how they occurred,

• ability to automate recurring actions,

• ability to spot bugs undetected by automatic tests,

• precision and eagle eye,

• knowledge of tools which facilitate the testing process,

• ability to write own automation tests,

• analytical thinking and ability to break bugs down into easily

analyzable parts,

3. Nice-to-have skills:

• the courage to speak their mind – a QA is person who is always

willing to prove you that you’re wrong.

Building Your Development Team 34

Players’ Bench
During different stages of the development process, you will need
different abilities of the people involved. For example, after some
time, the presence of a product designer may become less useful than
more effort from a front-end developer. In order to feel secure about
your product’s development, you need to have the option to switch
roles in the process.

You also need to take into account the fact that people will take days
off, they will fall ill and some of them will even leave the company
altogether during the development process. None of those events
should affect the development process. Having some additional people
on the players’ bench will guarantee the consistency and continuity
of work.

Process is the Key

Last but not least, don’t forget about the processes and the game strat-
egy. In football, there is a saying that the fans are the 12th player on
the pitch. In the development process, your 12th player is the variety
of processes that will organize the work of your team.

You need to have your processes worked out and written down BEFORE
you get to work. Determine the duration of iterations, velocity of
releases and communication rules. You can download our Project
Management ebook, where we collected our know-how and experience

Building Your Development Team 35

gained over 8 years of working on processes with clients ranging from
startups to big corporations. It will help you manage your projects more
effectively, master the best communication tactics and successfully
motivate your employees.

How Much Do You Know About Outsourcing?

In today’s globally-connected marketplace, you can go anywhere in

the world to find the skills you need to complete a project.

“Outsourcing” has been the traditional means of accessing develop-

ment talent, but the word carries negative connotations, and with
some very good reason. There’s an option that comes with less risk
and typically leads to better results: remote in-sourcing.

This process connects you with remote teams, but with a twist. Com-
panies that provide remote in-sourcing develop custom teams based
on your needs, and provide you with ongoing communication with
and access to that team. There is full transparency throughout the
process, and the idea is to create a remote team that blends seamlessly
with your internal staff.

The “remoteness” of the arrangement saves on costs – you are only

paying for the service the developers provide. This gives you access
to top talent at a rate you might not otherwise find appealing.

Building Your Development Team 36

How to Choose Remote In-Sourcing Partners Wisely?

There are pros and cons to scaling your project using a remote team,
but you can mitigate your risk by conducting advanced research on
any company you may be considering.

You will want to look at things like:

• Technical skill set of their developers.

• Transparency and accessibility in the sales process.

• Transparency of the development process.

• Testimonials from other companies.

• Proof they have completed projects similar in size and scope.

• Whether or not they tailor their process to meet your needs.

• How well they are able to blend their team with your existing
development staff.

• Whether or not you are invited to meet the people who will work
on your project.

• Your  ability to visit the company to see what their internal

operations look like.

• Contingencies for time zone differentials. Meaning, can you access

the group during your business hours?

Building Your Development Team 37

Not all remote in-sourcing companies are the same, and you want
to be confident that you can trust your product with the group you
choose to work with. Conducting due diligence up front allows you
to determine your comfort level.   Seek out a partner that values trans-
parency and makes you feel comfortable with the process.

Building Your Development Team 38

Working with
the Perfect Team
Working with Your MVP 39
Working with the Perfect Team

What You Should Be Looking for in the Perfect SaaS Devel-

opment Team

It’s okay - even encouraged - to be picky. You need your developers

to not only be highly skilled, but also to mesh well with your current
team and your company culture. You’ll be fine if you make sure your
team has these skills and uses these practices.

Code Review

If you decide to build your SaaS product all by yourself, then you can
never really be sure that your coding is robust enough during construc-
tion. Sure, you may be able to hash together a workable programme,
but, without other people checking and testing your code on a regular
basis, you’re more likely to let yourself “get away” with taking a few
shortcuts, or turn a blind eye to some glaring flaws that perhaps a few
colleagues would be more willing to pick up on.

In short, you need to assemble a team whose members all have the
same goal in mind – to create a durable, robust code structure that is
going to deliver to consumers exactly what it says on the tin.

Working with the Perfect Team 40

For the same reasons that writers need editors, coders need
fellow experts to pick over what they’ve done and pick out
the bits that need improvement. It can be incredibly difficult
to spot the flaws in your own work – but a dedicated team
will help each other through.

Cooperation and Communication

The key to success in almost every endeavour is of course communi-

cation. If you’re working alone, then you’re going to be spending a lot
of time talking to yourself – and if you’re the one asking the ques-
tions, then you’ll probably find yourself a little stuck when expecting
answers.

A great development team, on the other hand, will be a communicative

team. It will be a team full of people who ask each other questions and
keep each other – and the client (if it’s not you) – up to date precisely
with the progress of each iteration of the ongoing project. All members
will be proficient in and happy to use project management apps, and
will know exactly what it takes to run a successful IT project.

Put simply, your development team will be willing and able

to collaborate and communicate with everyone involved
with the project from the get-go, and will indeed share your

Working with the Perfect Team 41

philosophy that communication is everything when it comes
to success.

The Ability to Think, Work and Act Rationally

Development has no room for divas. Well, the world in general doesn’t –
but you know what I mean. Your team should have the ability to think,
work and act rationally – as a team. This means that there can be no
one person who in any way, shape or form adopts the “I know best”
attitude. In fact, attitude of any kind has no place at all in the dev
house. Problems will arise, and challenges will have to be overcome
– that’s all part and parcel of building great SaaS. But, what you don’t
want is a bad apple making things difficult for the communication
of the team.

Trust your intuition when hiring and weasel out any divas
or rock stars before you start to build – the success of your
SaaS project depends on it.

The Ability to Plan and Explain Work to the Client

If you’re heading up the development of a SaaS product on behalf

of someone else, then you need to make sure that your team is able
to communicate to that client in appropriate terms. Business people
are nearly always proficient at communicating their ideas, but pro-

Working with the Perfect Team 42

grammers are not always proficient in communicating complicated
processes in layman’s terms.

This, indeed, is a project management problem that you will

have to overcome, and it will involve dividing your project
plan into bite-sized chunks, creating lots of visual mock-ups
and graphs, and engendering a sophisticated communication
schedule that all members must rigorously adhere to.

Proficiency in Online Payment Systems and Processes

You will be undertaking the massive endeavour of creating

a SaaS product with the end goal of profit in mind – and you
need to pick a team that understands that.

At least one member of the coding squad should be proficient in build-

ing an extremely robust and, above all else, secure payment gateway
into your finished product. What is more, you need to make sure that
this person (or persons) understands the differences between payment
options, and, as such, will be able to advise and discuss with you what
is most suitable to the SaaS that you are constructing. Will a free-
mium model be best, for instance, or do you want to build a straight
up premium product? Cheapium is another option that is gaining in
popularity – and if you haven’t heard of it, or the reasons why some

Working with the Perfect Team 43

experts are arguing that it’s a better approach than freemium, then
this is all the more reason why you need an experienced person on
your team who is equipped to advise you.

Proficiency in Online Payment Systems and Processes

SaaS is a very particular type of IT product. It requires a team with

a very specialised set of skills, and a very clear understanding of the
security measures that need to be taken to ensure successful and safe
deployment to multiple subscribers. Additionally, SaaS architecture
means that a fast, secure and easy-to-use data services layer needs
to be developed – especially if you’re going to need to develop a public
API. Indeed, the success of your SaaS product will probably mean
that you are going to have to allow for its integration with other
software packages, and/or allow for development of additional capa-
bilities by third party developers, as well as providing services for
mobile applications

—and all of this requires consistent and dependable APIs.

The Skills and Expertise to Develop Mobile Apps

In 2017, the world is mobile – and that’s not going to change. Perhaps
you or your client at first conceived the idea of this great SaaS prod-
uct for desktops, but there will nonetheless come a time when your

Working with the Perfect Team 44

subscribers will simply expect to be able to access the product on
their smartphones and tablets as well. When it comes to SaaS, many
projects will require native apps developed separately to accommodate
these devices – so it makes the best sense to appoint a team which
contains members with the skills and expertise to develop mobile apps
from the start, rather than make your clients wait whilst you build
the mobile apps later. Indeed, you will risk losing your subscribers
to competitors if you go for this approach.

The current limits that HTML5 imposes on mobile applications mean

that creating a viable user experience (UX) on mobile is presently not
best practice, as David Key from Cloud Strategies explains:

The majority of SaaS vendors will provide both a desktop and mobile
application. While HTML5 is rapidly becoming de rigor on desktop, its
use on mobile platforms is situational based on the applications require-
ments. According to Flurry (April 2013), only 20% of the activity on mobile
devices takes place in a HTML browser (though B2B applications would
likely be different).

Understanding of and Experience in Data Collection and Man-

agement Systems

Working with the Perfect Team 45

Collection and management of client data is no walk in the
park – and, when the new regulations from the EU officially
kick in over the next couple of years, the seriousness of han-
dling people’s personal data cannot be overstated.

The EU’s General Data Protection Regulation (GDPR) means that

hefty fines are now in place to ensure that data protection rules are
taken extremely seriously by all companies which obtain data of EU
citizens – whether your business actually resides in the EU or not.
A company can now be fined up to 2% of its global annual turnover
just for not having its records in order or by failing to conduct risk
assessments on the data in its control.

Furthermore, 4% fines can be issued for more serious offences, such as

violations to data security and breaching the conditions of consumer
consent for having their data collected and shared. From a devel-
opment perspective, the most critical point about the GDPR is now
that privacy precautions must be built in by design and default – not
merely as an afterthought. This means that your developers have to
be building data protection facilities into your SaaS product right from
the word go, and you must be able to provide clear and unambiguous
evidence of this. No shortcuts can be taken, nor stones left unturned.
Users must also give clear and unambiguous consent for your SaaS
to collect their data, which must be confirmed by an action (such as
the ticking of a tickbox). Consent, indeed, can no longer be implied–

Working with the Perfect Team 46

i.e. just because people are signing up to your product does not mean
that you can assume that they wish for you to collect their data.
Consent must be actually given, not implied. Needless to say this is
serious stuff, and your development team needs to understand this
and ideally have experience in developing software that incorporates
data protection.

Readiness for Frequent, Non-disruptive Updates

Consistent, uninterrupted uptime is of course of paramount impor-

tance for SaaS – indeed, if you can’t deliver this, then you’re not cut
out for SaaS. One of the beauties of SaaS is that frequent updates
and innovations to the product can be delivered to the user, who
will always be enjoying the most up-to-date version of the product
whenever they log on to it.

But, this is no mean feat for your developers, who must know how
to plan and to execute these updates, all without disrupting the con-
tinuity of the service. This means that fault tolerant architecture
must be in place underneath everything, with robust fail-over plans
in place should difficulties occur.

Put simply, the software must be architected to anticipate

and recover from failures without any (or only minimal)
impact to the service.

Working with the Perfect Team 47

Your Team Could Make or Break Your SaaS Product

Really, the importance of choosing the right team cannot be over-

stated. You need people who will understand the importance of code
quality and implement code reviews to keep it at a high level. People
who will be able and willing to communicate well (among themselves
and with the client - or you), who will be humble enough to acknowl-
edge they can be wrong at times and to accept feedback.

Your team must understand the technologies your product will require,
such as online payment systems and security measures for SaaS.
They should be able to develop mobile apps if you have even the
smallest inkling that your users might demand mobile access some
day. You might also want to receive advice on data collection and
management according to current legislation, if you’re not an expert
on this yourself.

Finally, your team must be prepared for constant improvements

to your product and be able to build a scalable, fault tolerant archi-
tecture. Don’t be afraid to demand all of this from your team. After
all, it’s all in the best interest of your product’s success.

Working with the Perfect Team 48

Fixing Existing Issues

Scaling Your Existing SaaS MVP

If you have an existing product that you need to scale but efforts
have stalled, examine the issues that may have caused the slowing
of momentum:

• Talk to your developers to determine whether or not the issue

is the result of technical debt.

• Work with your CIO to establish the skill sets and resources needed
to continue.

• Examine your pricing model to see if margins can be increased.

• Study the feedback loop between sales, marketing and product

teams.

• Determine whether or not the CEO and other top-level execs are
too involved in the process.

After studying the root causes of your stalled efforts to scale, and
if your product does, in fact, have an audience hungry for the final
product, it’s likely time to partner with a development team that can
push you across the finish line.

Fixing Existing Issues 49

Recap

Hopefully we’ve answered most of your doubts and questions about

scaling a SaaS product. We’ve covered the steps that should be taken
before beginning the process, such as confirming assumptions and
gathering feedback from customers. We’ve talked about approach-
ing your MVP in the most effective manner, avoiding the dangers of
the freemium model, as well as building and using a feedback loop
to your advantage.

Two whole sections of this ebook are devoted to building the perfect
team for your product: a team that will possess all the necessary
skills and knowledge. Among those, there are some which people
often forget or don’t think of them as important, such as familiarity
with online payment systems and legislation related to collection
of customers’ personal data. These topics might seem boring, but
they could make or break your product, so you probably shouldn’t
neglect them.

Finally, we’ve provided a few solutions for ongoing scaling efforts

that went wrong somewhere. If you believe in your product, don’t
give up on it easily. Focus on finding the root cause of the issue and
don’t be afraid to ask for others’ assistance

Recap 50
Are You Ready to Scale?

If you have an MVP that you are ready to scale, but you’ve hit some
roadblocks, contact the team at Netguru. Or better yet, schedule a time
to stop by and see us in person. We have helped companies around
the world scale their SaaS products, even after they have stalled in
the early stages. Let us help you grow your product today.

You can:

• Talk to us on Twitter or Facebook

• Subscribe to our newsletter for more tips and resources

• Contact us directly: hi@netguru.co | +48 884 382 983