The Profitable Side Project

The Profitable Side Project
Handbook
a practical guide to developing a product business
Rachel Andrew
v.1.1 February 21st, 2014
The Profitable Side Project Handbook 1

1. Chapter 1: Why Side Projects?
1. Profitable Side Projects
2. Dreaming Small is Underrated
3. What defines success for your
product?
4. Getting to the Shipping Point
5. A Cautionary Tale
6. Minimum Viable Infrastructures
7. Small Things Can Grow
8. Take Action: First Steps to Launch
2. Chapter 2: Your Product
1. Software as a Service (SAAS)
2. One-off Purchases
3. SaaS vs. one off purchases
4. Plugins, themes and add-ons
5. Putting Your Main Product on
Hold
6. The Concierge Approach
7. Validating Ideas
8. Take Action: Your Product
3. Chapter 3: Productivity
1. Spend Time To Save Time
2 The Profitable Side Project Handbook

2. Tools and Techniques
3. Outsourcing
4. Take Action: Productivity
4. Chapter 4: Pricing
1. The Pricing Model for Perch
2. Step by Step Pricing
3. Customer Acquisition and
Lifetime Value
4. Card up-front or after trial?
5. Special Offers and Discounts
6. One Currency or Multiple
Currencies
7. VAT and Local Taxes
8. Take Action: Pricing Models
5. Chapter 5: The practicalities of selling
products online
1. Taking Payments
2. Hosting
3. Legal Matters
4. Stats and tracking
5. Take Action: Infrastructure
6. Chapter 6: Identity and Brand

1. Visual Identity
2. Identity Through Voice
3. Writing Marketing Copy
4. Take Action: Identity and Brand
7. Chapter 7: Setting up for Support
1. Support as Marketing
2. Support as Product Research
3. Tools for Support
4. Public Forums vs. Ticketed
Support
5. Social Media Support
6. Pre-sales and purchase support
7. Dealing with Difficult Customers
8. Take Action: Support
8. Chapter 8: Planning a Launch
1. Pre-launch Pages
2. The Slow Launch
3. Take Action: Next Steps to
Launch
9. Chapter 9: We launched! Now What?
1. Adding Features

2. Balancing Client Work with Your
Product
3. Marketing Your Product
4. Switching Focus
5. Enjoy the Journey

Chapter 1: Why Side
Projects?
Profitable Side Projects
This book is about creating profitable side
projects. It isn’t about building the next big
thing, and retiring on your millions in three years
time after an acquisition by Facebook. It isn’t
even about building businesses that will replace
the main income of your existing job, freelance
work or agency. This book is about launching a
product that will make enough money to pay its
way as part of your portfolio of revenue
generating activities as an individual or business.
A side project that is worth investing time and
money into, because it shows a return. A side
project that won’t be abandoned due to the need
to work on more lucrative opportunities.

Side projects are about more than just the money
you might make from them. Launching Perch
opened up a world of opportunities to learn and
develop my skills as a business person. Working
with clients we were often in the position of
needing to help them market products, by way of
the sites and applications we developed for them.
The things I learned through marketing my own
product could be fed back into our suggestions
to clients.
Developing your own product means that,

perhaps for the first time, you are also the client,
you get to make the final decisions. If you need
to bring in outside help to launch or develop
your product you may well quite literally become
a client, and in a later chapter I’ll share with you
some of the things I have learned by being on
the other side of the relationship. Even if you do
all of the work yourself or in house, the chance
to have total control and have no-one else

deciding to chip away at design decisions or limit
technical choices is an exciting, and sometimes
terrifying, thing.
It is possible to get many of these additional

benefits of a side project with a free product, but
as we will see in this book, things change when
you start charging and making money. The
expectations and feedback from your users will
be different and, as a business, once you start to
see your product as part of your total revenue
your focus is very different from that toward
something you just give away.
Dreaming Small is
Underrated
When I talk to my peers about our journey with
Perch, I often start to hear their own ideas and
dreams of the product they have always wanted

to build. Frequently it seems that the sticking
point is that this product has already become so
fully-featured, so large in their minds that they
are unable to get started on it, where would they
find the time? Launching something that solves
such a huge problem would take a huge amount
of development time, need a lot of money
invested up front. Or, they can only see the end
goal, the point at which the product is all they
work on, they are unable to see the progression
from being a freelancer or agency to being a
product business because they imagine they
would need to immediately switch from A to B.
It isn’t surprising that people feel this way. We’re

told to “reach for the stars” and to “dream big”.
The press is full of stories of entrepreneurs who
have risked it all, eaten noodles for three years
while sleeping under their desks and are now
basking in the glory of their acquisition. Big wins;
big stories make the news. The news rarely

reports on the hundreds of similar desk dwelling,
noodle eating hopefuls who are still clinging to a
dream that is unlikely to ever materialize. The
news also tends to fail to report on the many
small, successful product businesses that are
launched every day by people like you and I.
People who can develop something small, launch
it, make money from day one and develop it into
a nice business. A business that is providing
something of real value to its customers and
enough revenue to give it longevity.
Therefore I really do believe that many decent

product ideas are abandoned due to the gulf
between what we believe makes for a successful
product and reality. If your idea is likely to bring
in $20,000 per year of revenue, that is never
going to make any headlines. It is not going to be
of interest to any investors. However, if you are
currently a freelancer or running a small agency,
what difference would an extra $20,000 a year

make to your cash-flow? For many web designers
that figure is going to represent the income from
several projects. Success can mean many
different things, and the beauty of a side project
is that you get to define that success for yourself.
What defines success for your

product?
When we launched Perch, back in 2009, we
hoped to sell a copy per day. A copy per day at
£35 (about $56 USD) would mean that Perch
brought in, after deductions for payment
processing and so on, around £10,000 ($16,000)
per year. This was enough revenue to make the
product worth continuing to develop and to
ensure we could support the customers who
were using it. If your product is going to require
ongoing support and resources then you need to
have some idea of what constitutes enough

success to maintain it. How many customers and
accounts would enable you to see this as a
successful part of your portfolio?
Ultimately Perch surpassed our expectations,

selling more than four times that goal of one
license per day in its first year. However, starting
small and defining success as being quite a
modest thing enabled us to quickly get Perch to
launch, and getting something launched as soon
as possible should be your focus right now.
Getting to the Shipping Point

I expect most readers will be familiar with the
Lean Startup concept of the MVP (Minimum
Viable Product). It’s a term that is used to
describe a small product or feature of a product
that has been developed with just enough
features to make it viable - to be enough that
people will be willing to buy or sign up. I really

like the description in John Radoff’s blog post on
the subject,
“The goal of a startup is to find the

sweet-spot where minimum product and
viable product meet–get people to fall in
love with you. Over time, you listen to
your customers, make improvements and
raise the bar on what viable
means–making it more expensive for
competitors to jump in.” - John Radoff
The funded startup may well have the luxury of

being able to develop just enough of a product
that people will be willing to subscribe to a free
plan. If you are launching a bootstrapped
product then your aim should be to ship
something that people are willing to give you
money for as quickly as possible. This means
launching with the minimum that will make your
product something people are happy to buy.

Getting people to give you money is important
and not just because, as a bootstrapper, you need
it to continue investing in the product.
Launching with something free, or running a
long beta period may get you users, but won’t
necessarily get you customers. While those free
or beta users may give you feedback, it will be
very different from the feedback you get from
people who have paid for your product.
Perch launched as a paid version from the outset.

Other than a few early beta testers we have never
offered a free download or trial version of the
software and the initial version we shipped had
an incredibly tiny feature set. The core use case
of Perch is to be able to drop Perch tags into
your page, reload the page and then start editing
content in the administration panel. That first
version had image upload - content editors could
upload images - but no way to resize them. It had
no way to add new pages, there was no developer

API and so on. All of these were things that we
wanted to implement, however as soon as we got
Perch to a point where we thought we could sell
it, we shipped it.
Perch was developed over about four weekends,

as a side project. It was profitable, from license
sales, within 24 hours of launch. We’ve
developed, improved and refined it over the past
four years based on listening to our customers,
and keeping an eye on what is happening in the
web industry in general. It is now all we do as a
business, it has taken well over half a million
dollars in revenue, and continues to grow as a
product and in numbers of customers.
Although we continue to have great success with

Perch, prior to launching Perch we had another
idea that didn’t turn out so well. In fact it never
even launched, despite the fact we spent far more
time, energy and money on it than we did on the

first version of Perch. So I feel somewhat
qualified to include a word of warning in this
chapter.
A Cautionary Tale
It is something of a standing joke that every
developer wants to build their own bug tracker,
and we were no exception, coming up with an
idea for a bug tracker based on the “Getting
Things Done” methodology. We spent months
discussing and planning the feature set, alongside
our client work and even had an intern working
with us on the project for an entire summer.
Masses of code was written, features were tested,
we even started using it internally. However we
had such big plans for it that we could never get
to a point where we were happy enough to ship
it. Every time we started to work on it, we were
dreaming up new features and worrying about

various perceived defects - all before anyone
outside of our company had seen it.
Ultimately we gave up on it. Our interest and

energy had been sapped by endless revisions, and
the product had lost all focus and momentum.
We never got to see if it would have been the
next big thing in bug tracking. We never
benefited from seeing what people would do
with it; or got to understand the features that
other people will need. The longer you work on
your product before customers get their hands
on it, the more chance there is that you are
putting time into features that no-one wants. Get
to the shipping point with your product. Get it
into the hands of your customers. Start making
money and talking to real customers about what
they want.

Minimum Viable
Infrastructures
This book is less about your product and more
about the infrastructure that surrounds it.
However just as you can launch a product with
the minimum that makes it something people
will pay for, you can also launch a product with
the minimum of infrastructure around it. You
will need some things, but these days there are a
wealth of services that seek to provide solutions
to other startups. You can use these - even
temporarily - to get to launch quickly and then
iterate on your infrastructure as you do with your
product.
Taking time to consider your infrastructure, even

if you decide not to implement some elements
immediately is an important step in considering
what happens if you succeed. For example, and

as we will discuss in later chapter, most product
businesses are charging fairly small amounts
either as a recurring payment or a one-off for a
download. Managing all these small payments
from an accounting point of view is a very
different thing to dealing with the small amount
of high value invoices you might be used to as an
agency or freelancer. Putting in place some tools
and processes to ensure these are added to your
books in the correct manner will prevent a lot of
pain when you come to do your end of year
accounts. Thinking through that process will also
help you consider whether any tax rules apply to
your product, such as the VAT rules in Europe.
You can check with your accountant or directly
with the tax service what applies to you.
As we will consider when we talk about pricing

and pricing models, your infrastructure has costs.
Taking payment has a cost, third party solutions
you use for support or sending out emails have a

cost. Unless you have accounted for these things
then you may find that the price you choose is
too low by the time everyone else has been paid.
As you read this book be happy to throw out all
that does not apply to you, and in the things that
do consider your options balancing the fact that
paying for a service might get you to launch
more quickly against the fact you need to keep
costs down. If paying for that $29 a month
service saves you a week of time and means you
can start selling to customers a week earlier, it is
worth it. If there are no show stoppers, it is
worth it. You can always switch to something
else later.
Own your customers and data
On the subject of using third party services to get

to launch quickly, there is one area in which I
would not compromise. Make sure that the
services you are using allow you to export all of

your data at any time. The exception to this
would be credit card data, although some
payment providers do have methods of
transferring this, you probably don’t want the
liability and compliance issues of storing that
yourself. If you are using a third party to deliver
your product ensure that you get the customer
information and are able to contact these
customers. If you are using a hosted help desk,
ensure that you can export all the data. I would
advise that you routinely export and backup data
from the services that you use, just as you
backup your systems.
The data that you store about customers and

their interaction with your sales site and product
is valuable, even if you are not in a position to
analyze it as yet. Ensure that you have access to it
and that you are able to export that data in a way
that will be useful in the future. An export to a
CSV file will at least give you something that

could be opened and read in Excel or imported
into another system in the future.
Small Things Can Grow

Perch is not alone in being a side project that
grew over time to become a business in its own
right. Starting small does not have to mean
limiting yourself to a tiny product forever. What
it does mean is that you can grow sustainably,
using the resources you have. For example, not
having a mountain of funding to throw into
advertising means you are unlikely to suddenly
have scaling issues causing unreliability of your
SaaS application. Usage will grow over time and
you can add servers or improve code and
infrastructure to cope. You are unlikely to find
that overnight you have a thousand new users all
needing support, and no-one to help them,
leading to disgruntled people complaining on
Twitter.

As you will see throughout this book, there are
many stories of tiny products developing into
fully fledged businesses in their own right.
Starting with a small thing simply means you can
make that journey taking your customers along
with you, rather than waiting for your giant,
complex thing to be ready and perhaps finding
some other solution in the meantime.
Take Action: First Steps to

Launch
The aim of this book is to encourage you into
action. To help with that, at the end of each
chapter are a set of action points. Things that
you should be thinking about or researching in
order to move forward towards the launch day of
your product. This chapter is no exception. I’m
going to ask you to spend some time thinking
about these two questions before moving on to

the rest of the book. Write your thoughts down
somewhere, and keep your answers in mind as
you read on.
1. Imagine yourself one year on from

launch. What would define a successful
year one for your product?
2. What can you remove from your product

feature set right now that would make it
simpler and quicker to launch?

Chapter 2: Your
Product
This book is not about finding and testing ideas
and business models, that could be a entire
publication in itself. I am assuming that your
interest in this book is because you have some
idea or multiple ideas about products you might
like to develop as a side project. However I
wanted to briefly cover these subjects briefly just
in case you are reading this book as someone
who would love to start a product business but is
not sure what to get started with. You may even
be in the fortunate situation of having several
ideas to pursue. If that is the case, where should
you start? In this part of the book I will run
through some of the popular business models,
and the pros and cons of each.

Remember that for your project to be profitable
it, at the very least, has to pay its way as a first
class citizen within your existing business or
alongside your job. It needs to provide enough
revenue to make continuing to work on it
worthwhile. Bear that fact in mind through your
evaluation of possible business models and
product types.
Software as a Service (SAAS)

Not so long ago many people and companies
were wary of outsourcing key business functions
and important data to services hosted by a third
party. Today however, a substantial number of
companies run using very few internal, on-
premise applications and instead rely on software
hosted “in the cloud”.
To someone considering launching a product the

SaaS model comes with two main benefits - you

can fully control the environment that your
software runs in and each customer represents
recurring revenue.
Control of the environment
In a SaaS business you host the software on your

own servers. There is usually nothing for the
customer to install on their desktop or servers,
making onboarding of customers, the process of
getting them signed up and started with your
software, easy. The customer will normally be
interacting with your service via a web browser,
and so support for the software itself ought to be
minimal.
Control over the environment also makes fixing

bugs and pushing out new releases simpler. You
can simply make the changes and roll them out
to your app instead of needing to alert customers
to the fact that there is an upgrade and then wait

for the inevitable delay while users get round to
upgrading. With software customers install and
run on their own computers and servers, you are
never sure which version of the software they
might be running when they come into support.
With SaaS you know exactly what they are using.
If the customer is running into a problem you
can see exactly what state their account is in, and
may even just be able to fix things for them in
support.
Having this control over the environment does

mean that you are responsible for the uptime of
your service. How much of a concern this is
really depends on how mission critical your
service is to customer businesses. If you run a
project collaboration SaaS like Basecamp and
that service is down for half a day, then you will
have angry customers whose project information
was locked away due to the downtime. Work
hours would have been wasted and opportunities

lost by your customers. You will need to ensure
that, right from launch, you have a robust
infrastructure in place in order that your service
is reliable for your customers. If a SaaS is
unreliable people are more likely to start to
consider options that enable them to host the
software themselves.
Control of the customer
In addition to be able to help customers easily

when you have access to their account and
information. SaaS offers you valuable
information about how your customers are using
your software. You can use this information to
see which features of the application customers
are finding most useful, and work out why some
features are less popular. You can see where
users run into trouble - are there places where
people seem to struggle to complete a certain
task? Gathering information about how people

actually use the software can be hugely valuable
in making decisions about features and
improvements to existing workflow.
Right from the point at which a potential

customer signs up for your trial account you will
be able to see whether they perform certain
actions, and if they have done enough in the
product to properly assess it. You can use this
knowledge to trigger emails to the potential
customer to see if you can help with the process
of exploring the trial. You can do all of this
because the software is running on your server.
Recurring revenue
While control of the environment and customer

is useful, recurring revenue is the main driver for
the interest in SaaS by many entrepreneurs. If
your service costs $20 per month and you can
sign up 100 customers then the revenue over the

course of a year is $24,000. Finding 100
customers doesn’t seem like much of a big deal,
and at this point most of you are probably
running those figures in your head. 1,000
customers making $240,000 per year sounds very
nice, and still achievable.
The SaaS model is very appealing once sales

ramp up. However the infrastructure required to
host your service in a reliable fashion will be
required whether you have one paying user or
100. The SaaS model can work really well, but it
can take a long time to get to a point where you
are seeing the sort of figures your back of the
envelope calculations will provide. There is an
excellent video on the Business of Software
Conference website where Gail Goodman of
Constant Contact describes how to negotiate the
‘long, slow, SaaS ramp of death’. Those figures
you have in your head may well be achievable,
however it may take you some time to get to that

point. You may need to account for initial outlay,
without comparable returns for some time after
launch.
One-off Purchases
Some products lend themselves well to the one-
off purchase, and some markets would prefer to
have software that they install themselves and
control. My own product is a self-hosted CMS,
so much like with WordPress users download the
software and install it on their own server. Books
such as the one you are currently reading are
essentially one-off purchases too, as is a course
or perhaps a package of resources that you have
created to sell.
The advantage of the one-off purchase is that

you need far less infrastructure in place to be
able to sell a thing that people download. Selling
an e-book, package of resources or a piece of

desktop software may require little more than
providing a method to pay for and download the
product. There are a number of services available
that can provide that mechanism for you, taking
a cut of each purchase. In comparison to SaaS
you can find yourself in the nice situation where
you only need to spend money if someone
purchases - rather than having infrastructure sat
there just in case everything takes off. For high
value one off purchases, rather than a slow drip
of money into your bank account from monthly
payments, you get a nice chunk of cash in one
hit. It may be that over the lifetime of the
customer the SaaS model brings you more
revenue, but for a bootstrapper having larger
payments early on can enable more time and
money to be assigned to the product at an earlier
stage.
In terms of the infrastructure you need to

provide, with one-off purchases you have less to

worry about in terms of ensuring a robust
experience, and avoiding downtime. If you sell
your product from your website, and your site is
offline, the person who loses out is you - as sales
cannot be made. Your customer already has the
product and your downtime may not even be
noticed.
There are some obvious downsides to one off

sales, the main one being that you don’t get the
benefit of recurring revenue. Each customer may
represent just one single purchase, if you only
have one product. Therefore your marketing
efforts need to be very focussed on bringing in
new customers, and how much revenue there
will be each month can be much harder to
predict.
Acquiring customers can be more difficult in

some ways when compared directly with SaaS, as
you need to make profit on each transaction.

With SaaS, if you have a useful product that
people will be happy to pay for once they try it,
you can offer a free trial period or heavily
discount the first few months to encourage
people to start to use the service. Your cost to
acquire a customer may be more than they pay
for a month of service - but it is worth it if they
remain and become part of your ongoing
revenue. For low cost single purchases, many
advertising methods may be too expensive to be
worthwhile, and the level of discount you can
offer before the sale becomes worthless to you is
far lower.
For downloadable software, once you have an

interested customer, encouraging them through
your trial (if you have one) and purchase process
can be a disjointed process in comparison with
what is possible for a SaaS product. The SaaS
“sales funnel” usually involves a free online trial,
with the hope of encouraging that user to go on

to become a paid customer. As the customer is
trying the product on your servers you are able to
implement tracking to see how they are using the
trial, if you know that users need to complete
certain steps to get the most benefit from the
trial you can encourage them to perform these
actions if you see they have not. You have the
chance to perhaps email them with a special
price, if they do not sign up. Throughout their
trial you can see if they are still logging in and
using your service or if they have just logged in
once - and contact them accordingly.
Where you have a trial download of a one-off

product, that trial is happening in another
location so you don’t have the same ability to see
how the prospective customer is using the
software. This limits the methods that you can
use to encourage the customer to return to your
site and buy a license. It is often very difficult to
track a customer from initial acquisition, through

downloading or using an online trial, to purchase.
In addition you’ll find that because the SaaS
model is so prevalent a lot of the advice you read
online aboard onboarding assumes you can
access this information.
SaaS vs. one off purchases

My own product Perch is essentially a one-off
purchase of downloadable, self hosted software.
However we do have an element of recurring
revenue. Our target audience is web designers
and small agencies, they buy a license per website
that they develop. If we do a good job and they
enjoy using Perch then they will come back and
buy a license for their next site - we have some
customers with over 100 licenses. So it can be
possible to have the benefit of the one off
purchase, with some element of the recurring
income of SaaS.

Another possibility is to develop a suite of
products all with the same customer in mind, or
services that fit alongside your core product.
Selling to customers who already like and use one
of your products will be far easier than finding
brand new customers. Later in this chapter we
will discuss creating add-ons and plugins for
other products - something that can work well as
a suit of tools and products as you build your
reputation as an expert in the main product. We
will also take a look at the growth of the so-
called “concierge service”, something of a hybrid
of product and consultancy work.
In the course of researching this book I

interviewed a number of people who have
successfully launched products. When comparing
business models Ian Landsman, founder of
UserScape immediately came to mind. UserScape
have two successful products in the help desk
space, one is an on-premise app and the other

SaaS, I asked him a few questions about the
benefits of each model.
Interview with Ian Landsman
Q. You’ve been successful with a self-

hosted on-premise application with
HelpSpot. What drove you to move to
SaaS for your next product?
With taking our second product Snappy

SaaS, I really let the goals of the product
drive the decision. To have a customer
support application that is simple and
optimized for small teams and non-
enterprise audiences I think simply
requires a SaaS solution in most markets
these days.
I’m also really excited to be able to try

out the SaaS model and get hands on

experience with it. Obviously it’s a very
important delivery mechanism in our
industry these days so I feel it’s
important to have some in house
experience with it. It certainly presents
some challenges.
Q. What have been the positive

things about the SaaS model?
We’re still pretty early in the game so I

don’t have a definitive list but certainly
the thing that’s stood out the most to me
is support. Coming from an on-premise
application the support load per
customers is remarkably less in volume
and magnitudes less in complexity.
The root cause being the complete

removal of nearly every outside
dependency. There’s no installation, no

OS or other subsystems, no databases,
nothing the customer has to do and so
no support on all those steps. This leaves
basic pre-sales questions, bugs, feature
requests and usage questions. All of
which are much cleaner and simpler to
deal with.
The other big one is development

freedom. We can pretty much do
whatever we want when we want to,
which is certainly very liberating
compared to on-premise where you have
to careful plan migrations for customers
on a variety of platforms, from and to a
variety of previous versions and so on.
So much more development effort can
be spent on the product vs these more
ancillary elements we spend so much
time on with on-premise applications.

Q. What have been the downsides of
the SaaS model over self-hosted?
There’s certainly a few downsides. The

most glaring is the revenue stream. At
least for us where with HelpSpot a
normal sale will be $1,000+ getting sales
of $10, $20, etc is a very noticeable
difference. Of course, month after
month year over year those add up but it
has given me a little bit more insight into
the VC world as it exists today. I can see
how many companies are essentially
forced to take VC money these days
because the way the revenue streams
work in SaaS. It takes a significant
amount of time to get to solid revenues.

Plugins, themes and add-ons
If you already use third party software in the
course of offering services to your clients - for
example if you mostly offer services using
WordPress or ExpressionEngine - then a great
first step into products is to create an add-on or
theme for another product. If you know a
product well you are probably already aware of
things that would be really useful as add-ons, you
may even have created some for your own use.
In many cases products have an established add-

on community and this can make the job of
selling and marketing your add-on much easier,
as there is an established channel to do so.
Rather than having to find completely new
customers you can target customers who are
already using the main product. The
ExpressionEngine add-on community is a great
example of this, with the devot.ee site claiming to

offer almost 2,000 ways to extend
ExpressionEngine through the add-ons listed on
the site. These add-ons range from very small
additions right through to fully featured add-on
products such as online stores. Several add-on
developers have become very well known in the
community and have created nice businesses
creating add-ons to a third party product.
If you use WordPress for your marketing site

then you may well find that the WordPress
plugin AB Press Optimizer is useful to you, it
helps you to perform A/B Testing on your
WordPress site without needing to use a third
party hosted service. I spoke to Ivan Lopez, the
developer behind AB Press Optimizer as I had
listened to him interviewed on a podcast and
knew that he had switched from developing a
SaaS business to the plugin. I thought it would
be interesting to hear about the motivations

behind switching product idea, and also to hear a
little about the business of selling plugins.
Interview with Ivan Lopez
Q. You were initially working on a

SaaS product, what caused you to
switch focus to developing a
WordPress plugin?
In the process of building Project

Conductor I was trying to run A/B test
on my landing page in order to optimize
the signup process for my mailing list.
My landing page was built in WordPress
and all the plugins out there required me
to create separate pages of my landing
page making a mess in the pages section.
I could’ve used one of the SaaS A/B
testing solution but because Project
Conductor was a side project that was

not really in the budget. So I decided to
scratch my own itch and take two weeks
to plan, build and launch my plugin.
Q. How did it feel to make that

decision to switch focus?
Switching focus from a SaaS to a plugin

was almost like a relief. The process I
was taking to build my SaaS was very
loose as it was a side project. I kept
setting a due date and when other
responsibilities and projects got in the
way I would simply move the due date.
At the beginning of AB Press Optimizer
I committed to changing my approach. I
gave myself a concrete end date. If I
made the deadline the plugin would be
launched and if I missed it the plugin
would be trashed. I felt that the strict
deadline gave me direction and helped

me fight the urges to add more features
than what I needed for launch.
Q. What did you do differently when

launching this new product in
comparison to working on your first
product?
The main difference on this product

from my SaaS was the strict deadline.
This allowed me to buckle down and get
it done. It also gave me a faster feedback
loop because of the lower price point. In
the first 48 hours, I had my first sale and
shortly after that I had my first support
ticket. This instant customer feedback
allowed me to continue to tweak and
improve the plugin quickly over a short
period of time.

Q. Do you find yourself dealing with
a lot of support that is not really your
problem - for example hosting issues
or issues with WordPress itself?
Initially I was getting a lot of support

tickets. There were several bugs that my
customers helped me smooth out.
Currently one of the most common
issues is assisting customer to implement
the type of experiment they want to do.
The type of experiment they usually want
to run is one that does not lend itself to
simply throwing a ShortCode on the
page. Now that’s not really my problem
but I believe that by assisting them I get
a better understanding of what they are
trying to test and hopefully get more
ideas of what features to implement in
order to solve any of the repeatable
issues.

Q. What advice would you give to
someone thinking of launching a
WordPress plugin?
If someone was planning to launch a

WordPress plugin I would probably
advise them to figure out who their
plugin is for. Is it for developers or end
users? This could really help them in
planning out what features and UI. I
would also recommend to take time to
write very detailed documentation. If you
can make a few screencasts even better.
Finally make sure you look at other
plugin sites and see how they are
handling refunds. You will get requests
from people that want a legitimate
refund because the plugin won’t work on
their environment to people saying that
they decided not to use your plugin.

Putting Your Main Product
on Hold
Several well-known people in the bootstrapping
community recommend that potential
bootstrappers start out with a small product first,
something that requires a short amount of time
to get to launch, rather than going straight for
their big idea. Products such as e-books are often
cited as a great way to get started, and to start
seeing revenue that is not tied to you swapping
your time for money as a consultant or agency.
An e-book or other small product may well be
exactly what you have in mind, and there really is
no such thing as too small to be worthwhile
when it comes to side projects. However if the
side project you are keen to do represents a lot of
initial work and investment, the idea of starting
out with something less challenging might
appeal.

There is certainly sense in this approach if you
have a range of possible product ideas, as you
could pick off the one that would be quickest
and simplest to get to market first and focus on
that. In particular if you can find a small product
that will serve the same customer base as other
products, then you might find that your first
product can help you to not only get some
product based revenue but also build your
reputation in the community that you want to
sell to.
I asked Ian Landsman of UserScape what he

thought about this idea of launching some small
product first, in order to get your feet wet and
earn some product-based revenue. He has some
misgivings about the idea - thinking that perhaps
it might just become a distraction.
“This is one I’ve been kicking around a

lot. Certainly it’s the trendy new thing to

do. My initial take on it was that the
people pushing this trend want to sell
their courses and books and it’s much
easier to sell something that has a small
easy goal than a large complicated one
like starting a software company.
However, I’ve come back off it a hair.

When I started UserScape my little
personal blog pretty much got us rolling.
Blogs weren’t everywhere then and I
could make connections with people
more internet famous than myself,
people in all different places who would
link back to me and talk about what I
was up to. With the proliferation of
communication tools and the sheer
volume of blogs, tweets, etc starting
from scratch today is significantly harder.
You can’t make connections so easy, you
can’t be found or stand out as easily.

So, as a pure marketing initiative I think
it could have some benefit. That said, I
think it only really works like that if
you’ve planned that out pretty early on.
So that your info-product helps you
build up a community that directly
relates to the real product you want to
build. A lot of the material I’ve seen
doesn’t seem to emphasize this and if
you don’t do that then I start to lean
back towards it mostly being a waste of
time.
A mailing list of people who you sold a

Rails tips ebook to probably aren’t a
great group to sell your $49/month
CRM app to so you’ve gone ahead and
wasted a year to make $8,000 on an
ebook and build a list you’ll sell a few
accounts in your app to and that’s it.

Personally, I’d have a hard time
recommending this method myself.
Primarily because of that planning I
mentioned above. If you haven’t built a
product or run a company before your
ability to plan out a strategy from ebook
to mailing list to app probably isn’t
honed enough yet. Worse, it could lock
you into a path that’s wrong, but which
you now feel stuck with because you
have 300 people on a mailing list.
If your goal is to have a product you

should put your time and effort into that
and consider some info-products around
that as marketing but not as primary
initiatives. They’re likely free and
designed entirely to drive sales of your
product and not be revenue generators
on their own. But maybe I’m just too old
school!”

I would tend to agree with Ian on a lot of his
points. Unless you are already very high profile in
a particular community then your e-book or
other info product is unlikely to make you a great
deal of money, you would probably be better
continuing to work on your client business.
There are skills you could learn by promoting
that smaller product, but as my own story shows,
you can learn these things as you go along
whatever the scale of the product.
Where I can see value however is if the small

product is part of a longer term plan. Perhaps the
first step in selling to a particular audience is to
launch an e-book. The book might not be a huge
revenue generator in itself, however if it is well
received then it will increase your credibility
amongst your target audience and perhaps help
you to build up a list of contacts that you can
email when you launch your larger second
product. In some ways the e-book can act as a

precursor to the main event, building up trust
amongst your audience and also giving you a
ready made pool of people to talk to, and test
your assumptions for the main product with.
While this isn’t a route I followed, there are a

number of successful entrepreneurs who have
used this tactic. Brennan Dunn, while he actually
launched his SaaS business prior to writing his
book, “Double Your Freelancing Rate” found
that with a book speaking to the same audience it
reduced the barrier to entry for that audience
trying out his app. As he notes in his post Giving
up a million dollar consultancy, “It’s a lot easier
to read a book than it is to switch up project
management software”. If your end goal is to
build a product based business - rather than just
making that burning itch of a side project
profitable, then looking at the path that Brennan
has followed would be very much worth your
while.

If you are weighing up two options, then I would
suggest tackling the simplest first. If you have a
lot of specific and high value knowledge from
your consultancy business that can be easily
turned into a product to give you some recurring
revenue and time to work on your main idea -
then go for it. If you have a small product that
will help you to develop a following and
customer base that would transfer to your bigger
idea, then developing that product as part of
your wider plan could well be worth the time
spent in terms of customer acquisition. However
I wouldn’t particularly advise sniffing around for
something easier to work on if you do not fall
into one of the previous groups. It is likely to just
end up a distraction, and not even a particularly
enjoyable one if you would rather be focussing
on your main product idea.

The Concierge Approach
Over the past few months a strong theme has
developed in many of the podcasts that I listen
to - that of concierge products, “productized
consulting” and the “concierge MVP”. A
concierge service is something of a hybrid
between services and products and can be a great
way to step into the product business without the
need for a lot of initial development time prior to
launch. A concierge service can also be a great
way of bridging the consulting/product company
gap as it will use many of the skills you already
have in your agency or as a freelancer in terms of
dealing with people.
A concierge service involves you doing

something on behalf of your customer. A great
example of this type of service is the WordPress
support business wp curve. This company has
essentially turned a consultancy service - helping

people maintain and update their WordPress
sites - into a product, with a monthly
subscription and some limitations on what jobs
can be carried out. Dan Norris, one of the
founders of wp curve, had his first paying
customer four days after thinking up the idea.
Creating this kind of hybrid between a product
and a consultancy business can get you to
profitability fast and without a lot of up front
cost. If you are already selling freelance services
then it might be that your existing clients would
be interested in a more product-like arrangement.
It may be something you could sell as an add-on
once their site is complete.
You can also take a concierge approach to things

that you ultimately hope to automate. This can
help to get your product launched more quickly,
cutting down on development time, but also
allows you to see what people are really
interested in paying for before you invest the

time and money into a feature or set of features.
This can work really well if, after signing up, your
customer has to go through a number of steps to
get the most out of your product. Maybe they
need to install something on their server, perhaps
they need to set up templates or schedule emails.
Ultimately your aim may be to develop tools that
make all of this incredibly simple and easy to do.
Creating these tools will take time, and at launch
you may not even have enough information to
know what tools you need to build. Therefore,
during a beta period, or even post launch you can
help your first customers through that process by
offering to do things for them to get them
started. In the process of helping those initial
customers you will gain a huge amount of
information about their goals, difficulties and
what they hope your product will help them
achieve. Taking a concierge approach may help
you to refine your feature set and only build

those tools that are really going to be helpful to
the customer you want to attract.
Do not worry about doing things that don’t scale

in the early days of your product. Yes you will
make more profit from a customer once those
set up tasks are automated however getting to
launch with paying customers should be your
main focus early on. In addition what you learn
from walking alongside your customer is likely to
be more valuable than the time you would save
by having everything automated from the start.
Rob Walling believes that SaaS companies

operating in crowded markets may well need to
start offering a concierge service alongside their
product in order to differentiate themselves from
the competition,
“There’s a lot of Saas apps. The secret’s

out that Saas is subscription revenue and

that it’s a really good way to go if you
want to launch a software company. And
so in order to set yourself apart, you
have to do things that other people
won’t and a lot of developers who can
write code don’t want to do any type of
– basically the schlepping […] a lot of
developers are going to avoid this and so
that makes it more low hanging fruit for
people who are willing to do stuff that
doesn’t scale in order to get their
business off the ground and concierge is
one of those efforts.” - Startups for the
Rest Of Us, episode 162
Scaling slowly while learning from your

customers is one of the hallmarks of the
bootstrapped product. I think that using a
concierge approach fits well into that model for
many of us.

Validating Ideas
In my opening for this book I talk about how
side projects don’t necessarily need to be an idea
that is capable of being the next big thing. They
don’t even need to be big enough ideas to make
an entire business out of. This means that
validating an idea for a side project is a different
matter than if you are trying to find an idea that
will warrant investment, or is capable of turning
into a business in its own right. A profitable side
project may well be part of a portfolio of
business interests, alongside consultancy or other
small products. It can pay its way, it is worth
investing time and energy into, but it doesn’t
need to be a “big idea”.
I would strongly advise that the market you go

into is one you already understand and hopefully
one in which you are known as an individual or
company. If you are a web developer then

creating a product that is useful to other
developers is an obvious start. However perhaps
as an agency you have a track record of
developing websites for schools, are well known
in that field, and have been able to gain
experience in and understanding of the problems
schools face. In that case developing a product
aimed at the education market would make sense
and you already have insight and an ability to
contact and talk to people who would be
potential customers.
Many side projects are small enough for a

minimum version of the product to be built and
launched in order to see if there is a market. In
the case of Perch this is exactly what we did. We
had a landing page up, but by that point most of
the code was written. We built the product in the
simplest form that we could and launched it. If
your side project will only take a short amount of
time to develop, is something you will enjoy

creating, or perhaps - like Perch - would be
useful in your business anyway then it may be
that you don’t need to do much in the way of
validation.
If your product idea will take too much time to

develop to find that people are not interested, or
you have a number of ideas and can’t decide
which to tackle first then you may want to try
and validate the idea more formally before
starting work. The following advice can also be
useful even if you are likely to build the idea
anyway, as in the process of validating the idea
you will hopefully find out more about your
target customer and the problems they hope your
product will solve.
The Landing Page MVP
Some side projects can be validated by way of a

“landing page MVP”, by putting up a landing

page describing the product, and seeing if people
are willing to sign up for more information. This
is the method by which I validated the idea for
this book. I would probably have written it
anyway but the rate that people signed up for
more information and the number of emails I
received from people asking when it would be
published, certainly encouraged me in the idea
and gave me an incentive to get down to the
writing process.
You can use Google Adwords or other

advertising to drive traffic to your landing page,
using keywords that people with the problem
you are intending to solve might use. This will
help to demonstrate a need, and that people are
even searching for a solution. Hopefully some of
these people will also sign up for more
information. Some founders have gone so far as
to take pre-orders from their landing page, the

ultimate validation is if people are willing to give
you money for your idea.
Talk to people
You need to talk to potential customers, and do

this as early and as often as possible. It is very
easy to think you know what potential customers
will be interested in, to see a problem in their
workflow and believe that you have the perfect
way to solve it. If they are not interested in fixing
that problem, or don’t see it as a problem, your
great idea will get no traction. Patrick McKenzie
(@patio11) has the following advice on selecting
a problem to solve,
“The ideal product for a bootstrapped

company solves a problem which is well-
understood but poorly solved. There are
probably many competing ways to solve
the problem, some involving employee

time and paper, some involving
spreadsheets, and some involving one of
several competing software solutions,
none of which have dominant market
share. ” - Patrick McKenzie
Flesh out your idea, be able to clearly articulate

the problem that it solves and why it will be
better than existing workflows, then talk to
people. Talk to your ideal customer and find out
whether the pain point your problem is designed
to solve exists for them, and would they be
willing to pay for something that solved it in a
better way that what they are doing currently.
Make sure that you talk to a range of people in
your target audience, and make sure you talk to
people who have no reason to be nice to you.
Your friends, seeing that you have put work into
this idea, will be more likely to make encouraging
noises so as not to disappoint you. If your
market is large enough that your product is even

slightly viable then finding five to ten people
who fit your ideal customer profile should not be
hard. If you cannot find these people now then
you are probably not going to be able to find
them after launch!
When talking to people remember to ask open-

ended questions about their workflow and
problems. It is tempting, once you have someone
in front of you, to simply sell your proposed
solution to them. If you do this you lose the
opportunity to discover the real problems that
they are facing, problems that may well lead your
product is a different and better direction than
you had first imagined. At some point in the
process you will want to introduce your product
to them, and the problem it solves - as Kunal
Punjabi notes,
“Look out for patterns – groups of

people doing things the same way, or

complaining about the same thing and
either observe or ask them how they
solve those pain points today. Keep in
mind, however, that sometimes users
don’t know they had a problem until
they’re shown the solution (your
product). Dropbox is a classic example
of that. Just remember that you’re there
to observe, listen and learn – not to sell
your test subject on your product idea.”
Kunal Punjabi
Entering crowded markets
My product is a content management system,

we’re in a hugely crowded market, we have major
competitors that are completely free of charge
and yet we have managed to build a good
business. If there are a lot of products that
attempt to solve the same problem then it
demonstrates there is a need. You just need to

make sure that you can explain what makes your
product different. What particular problems does
it solve, and why does it do so better than the
competition?
Take Action: Your Product

Your next steps after reading this section depend
on how progressed you are already with your
product idea. However, if you have not yet
started to talk to potential customers about the
idea I would make this a high priority whichever
stage you are at. If you are still deciding between
ideas then set up discussions with potential
customers for each idea. You may well find that
this will cause one or other to rise firmly to the
top as a stand out problem just waiting for a
viable solution.
Validating the idea
1. List the problems your product will solve

2. Find at least five people who you believe
would be ideal customers for the product
3. Set up meetings with those ideal
customers in order that you can find out
more about the problems they have, and
run your product idea past them.
Consider the following
1. How much time do I have to work on

this project?
2. How much money am I able to put into it
before it starts to bring in revenue?
3. Is there any aspect of the product that
would benefit from a concierge approach?
4. Could I get to launch quicker if I do some
things that don’t scale?

Chapter 3:
Productivity
The work to develop Perch and the initial
infrastructure was something that Drew and I did
in our “spare time”, at evenings and weekends,
alongside our very busy services business. If you
are developing a product as a side project then
hopefully you are creating something that you are
interested in and excited about, so spending your
own time on it is an agreeable prospect. That
said, and in particular if you have a family or
other commitments, spending every waking hour
on yet more work may not be possible.
Unless you already have a bit of a runway of cash

in your existing business that allows you to assign
business time to the product before it makes
money, or are able to take some time off your

day job in order to spend a good chunk of time
concentrating on the product it is likely that
some out of hours working will take place
initially. The key here is for that time to be finite,
to have an end date, and if the product will
require ongoing work after launch you have
planned for how it will fit alongside your other
commitments. This is where being able to put
limits on the scope of what you will ship early on
will help you. Once you know what you are
going to launch with, you can start to plan for
the time needed up to that point, see an end date
and perhaps share that with family members who
would probably also like to see when they will
have you back at weekends!
Even if you do not have other demands on your

time, giving things a completion date is a very
powerful motivator. Side projects can easily
become a formless, endless thing that you play
with “whenever you have time”. The danger here

is that you never really get to launch. Set a
realistic date for your launch, and try your best to
meet it.
Brian Casel, in his article The Cascading To Do

List, outlines a helpful approach for getting large
projects done. He advises deciding on your six
month goal, this might be “launch my side
project”, then working out all the things you will
need to do to get from where you are today to
completion and splitting that down into monthly
actions. From those monthly actions you can
plan two week sprints, from a two week sprint
you can work out what you need to be doing
each day. This sort of approach can help you to
maintain progress towards a bigger goal but I feel
is also very helpful if you are using your free time
to get your side project launched. If you have
worked out what you need to achieve today, and
you complete it, you can feel happy to go to the
gym, spend some time with family, or just relax

safe in the knowledge that you have done what
needs to be done today. It is so easy to feel as if
you have to be plugging away at your project all
of the time, realistic planning can help you to
give yourself a break.
Spend Time To Save Time

If you want to be productive, especially if you
only have short bursts of time to devote to your
product, you need to make sure that your
working environment and tools are in good
shape. If you only have two hours a day to work
on something, you want to avoid spending 30
minutes messing about with your development
environment or troubleshooting a slow
computer.
Devote some time at the start of your project to

getting yourself set up, with everything you need
for the foreseeable further so you have no

roadblocks to getting started and doing things
properly. If you don’t have source control set up
yet, or need a development environment, or will
require access to a third party API or test service
then schedule in sorting those things out. A bit
of time spent on setup and admin will enable you
to sit down and start work more quickly - giving
you less opportunity for procrastination!
Tools and Techniques

Productivity is an immensely personal thing and
no single solution is going to work well for every
reader of this book in terms of tools and
techniques. The productivity industry is vast
because everyone is searching for that one thing
that will make them twice as productive, stop
procrastination and enable them to ship things
faster.

I am going to share here what I find works well
for me, and some time-honoured productivity
tricks. Ultimately however, you do just need to
sit down and do the work. Avoid spending too
much time searching for the perfect tool or
technique and instead find things that generally
work for you, and seek to improve your
processes incrementally.
Getting Things Done (GTD)
I follow in most cases the Getting Things Done

methodology, as detailed in the Book Getting
Things Done by David Allen. I think that most
people will have come across GTD at some time
so I won’t go into detail here, however I think
there is a key part of the method that really
works well for people like us, who have a
number of different things vying for our
attention at any one time.

Most of us have a whole range of places where
the things we need to to stack up. Physical in-
trays at home and at work, multiple email in-
boxes, perhaps in Facebook messages and
Twitter replies, project management tools, that
pile of paper on your desk and also in your brain.
The first step in a GTD workflow is to collect
everything into one place - and that includes
writing down everything you currently store in
your head. As by trying to remember all of the
things we have to do, we end up spending a lot
of time and energy just remembering all the
things we need to do.
When I was trying to split my time between

client work, Perch, my writing and speaking and
home life, at first I would try and separate all of
these things out into different systems. I ended
up with a home to do list, client work in our
project management system, Perch work in
another system and a rough to do list of writing

tasks. This was really an artificial constraint. I
might be in the office but if a phone call to my
daughter’s school needed to be made it was in
the home to do list and I couldn’t find the name
of the teacher I needed to talk to. I would be
waiting for a client to get back to me and have
some time to work on Perch but that involved
switching systems just to see what needed doing.
For me putting everything, for every aspect of
my life into one system was huge in terms of my
ability to be productive wherever I was.
In addition I find the concept of Next Actions in

GTD a useful way to look at large projects.
Asking yourself, “what is the next thing I need to
do to progress this” is a far easier question to
answer than, “how am I going to do all of this
stuff?” As much as anything GTD enforces
some structure and a workflow that I find
helpful. If you want to read more about the
technique then starting with the original book

Getting Things Done is a good first step and
there is plenty of information on the web about
how to integrate GTD principles into your
workflow and with other tools that you use.
Productivity Software
There is a vast amount of productivity software

available ranging from very simple to do list apps
to full project management applications. If you
are trying to find something that will help you
organise your life then ask the following
questions before starting to review applications.
From where do I need to access the

application?
I want to be able to add to do items from

multiple locations - from my desktop, my laptop
or when I think of something out of the office so
want to add it to my phone. I travel a lot so also

can’t be sure of having an internet connection at
the point I want to view my lists or add
something. Therefore a completely online service
is not appropriate, but something with sync
across devices that has a desktop and iPhone app
is perfect.
Do I need to give anyone else access to my

to-dos?
If you want to be able to share to do items or

assign items to other people in your team this
will not be supported by all applications as many
are focussed on personal productivity. So decide
if this is likely to be an requirement before
testing systems.
Do I already have a system that I need an

app to support?
If you like the GTD approach for example then

you will want an application that can support this

way of working. Many apps do have a certain
approach or methodology baked in, so if you
already have a preferred way of working you may
find it works against you.
Do I need the app to play well with other

tools?
There are to do lists that integrate with email,

with Evernote or with SaaS applications such as
Basecamp. These can be very useful if you
already have tools in your workflow and you
want to be able to pull tasks from those other
tools into your to do list app.
Having a clear idea of what you want from an

application can help you quickly create a shortlist
of apps to try out, which support most closely
your requirements. This will bring focus to your
testing and help you avoid wasting time reading

review and trying out applications that
fundamentally won’t work for you.
I’ve avoided recommending one solution over

others in this section purely because productivity
is so personal to each of us. However I use
OmniFocus following a GTD methodology. I
personally like OmniFocus because it works well
for GTD and crucially for someone who is often
on an airplane uses sync rather than needing a
constant internet connection. I can add items to
my iPhone app while offline and it will then sync
up once there is a connection.
I do think that having some sort of system that

helps you to plan your day is valuable. However
it could be as simple as a text file in Dropbox or
even a notebook you keep with you. The
important thing is to find something that works
well for you, rather than trying to fit into
methodologies that suit other people.

Productivity geeks can be evangelistic about their
tools and methods, don’t let them sidetrack you
into a search for the perfect solution!
The Pomodoro Technique
Along with Getting Things Done, the Pomodoro

Technique has made a huge difference in my
personal productivity. The technique is very
simple, you choose a task to work on, set a timer
for 25 minutes and work in a focussed manner
on the task throughout that time, after 25
minutes you take a short break and then the
timer runs again. After four pomodoros (timed
sessions) you can take a longer break.
I find the Pomodoro Technique is excellent at

keeping me focussed through long tasks. For
example I enjoy writing and delivering
presentations, but I do not enjoy creating the
slide decks. I’m not a major procrastinator, but if

I have to create a slide deck everything else that
could possibly need doing becomes very
interesting to me! The Pomodoro Technique
helps me to work in a focussed way on that task
and see progress through the day. It’s very
simple, and works well alongside GTD as if I
finish one task I can move onto the next action
that I have until the timed session finishes.
You can buy the tomato timer if you like, there

are also apps that you can use instead. I use a
Pomodoro Mac App that works well with
OmniFocus, so rather than typing in the task I
am starting on I can just select it from the list of
actions I already have. It’s a simple technique but
seems to work very well for a lot of people - try
it for a day and see how you get on.

Outsourcing
At some point in developing your product you
may find that you need or want to outsource
some of the tasks that need to be done. In our
case neither Drew nor myself are designers. We
can put together a website that isn’t a complete
disaster, but ultimately things we design tend to
end up looking as if they have been designed by
programmers. Before Perch launched we
contracted a designer that Drew knew to work
on the user interface and to ensure that our
product, aimed at web designers, wasn’t a turn
off to the very people we were trying to market
to.
We have managed to stay a team of two until this

point by finding and maintaining good
relationships with the freelancers who help us.
Our philosophy is to find good people and to

treat them well so that hopefully they will want
to work with us again in the future.
Outsourcing to bring in skills you

don’t have
We still work with Nathan Pitman of Nine Four

on the Perch UI, and have not yet felt the need
to employ a full time designer, as we feel our use
of a small team of freelancers and other agencies
actually means we can get the best person to do
each particular design job as required. For
example the birds were illustrated by Kev
Adamson, we also work with Laura Kalbag who
designed two of our demo sites. We are fortunate
in that we already know a large number of
designers, but even so, good designers are often
very busy. How do you go about finding people
to outsource design work to?

When we decided to redesign the Perch
marketing site prior to the launch of Perch 2 we
knew that we wanted something a bit different -
although we weren’t completely sure what. We
also knew that the people we might approach to
redesign the site from our own list of contacts
were very busy, and we had a reasonably short
timeframe before we launched. There are various
sites such as oDesk that you can post projects to,
however it appeared that posting to one of these
sites would result in a lot of people contacting us,
whose work was fairly low quality. I didn’t have
time to wade through a whole stream of poor
quality work to find someone who I would trust
with our brand.
It was then that I came across Folyo, founded by

Sacha Greif. Designers apply to be listed on
Folyo and their work is reviewed before they can
join the site. Sacha is a designer himself and so
the designers who become part of the site are a

far higher standard that those you might find on
listing sites that are completely open for
membership. If you sign up as a client to post a
job, Folyo also gives guidance on how to create a
good job ad, useful for those of us trying to
outsource or the first time! When you list your
job offer you are encourage to include budget
and timeframe as this ensures that the people
who contact you feel they can fulfil the brief
within budget and on time.
The responses that we received from designers

on Folyo were incredibly good quality. Through
the site we found designer Paddy Donnelly of
Lefft. He wasn’t someone we had met prior to
contracting him for the Perch 2 redesign process
but he has now helped us with a number of
projects once the initial work we asked him to
do.

For us design is absolutely key to the success of
Perch, and many people would think outsourcing
something so important to the product is a bad
idea and that the only possible course of action is
to hire an employee. However our experience
shows it is possible to create a network of great
people who work on projects as required.
Outsourcing things you can do but

shouldn’t do
Like many people who work in the web industry

I am able to turn my hand to most things if I
need to. When you run a small company you
have to learn skills that are outside of your main
skill set and interests. It is easy for the fact that
you can do something make you feel that you
should do it, that it will save the business money
if you do these tasks rather than getting someone
else involved.

When we ran a services business I did all of our
day to day bookkeeping. We had an accountant
who did the end of year work, made sure that we
paid the correct amount of tax and so on, but I
did all of the day to day work to keep our
accounts up to date. For a services business, with
a few invoices sent out per month and a few
expenses to record, this didn’t take up much of
my time. As we moved to products I found that I
was often spending half a day to a day a week
making sure that everything reconciled. This was
not a great use of my time! We found a local
bookkeeping service who work on a retainer
basis, so we buy a certain number of their hours
per week and they ensure that our books
reconcile and create a list of any particular issues
that I need to look at each week. This means I
can be fairly hands off with the books, just
looking at the odd transaction that hasn’t made it
through an API for some reason. As
bookkeeping isn’t my main skill there were also

plenty of places where our bookkeeper has
improved the records that we are keeping,
ensuring that proof of expenses are correctly
kept and that things end up logged under the
right categories. I feel a lot more confident that if
we were to have a tax inspection, everything
would be just as required, and can spend my time
and energy focusing on moving the business
forward.
In addition to things that you can do but don’t

enjoy, or take longer than a specialist would to
achieve, there are things that perhaps are
something you do professionally but your
business would benefit more if you were to
spend your time working on something else. In
our case for Perch this is often front-end
development. Both Drew and I are experienced
front-end developers, we have both written on
the subject, in our client business we often did
front-end development for other companies.

Therefore it would seem to make sense that any
front-end development work, we would just sit
down and do. However us spending two weeks
building our marketing site is less valuable to the
company than me spending two weeks working
on the business, or Drew spending that time in
the core of the product. So we often outsource
these front-end builds to freelancers.
You have to learn to let go, and accept that

things won’t be done exactly as you would doing
when outsourcing things that are part of your
own core skill set. A freelance front-end
developer won’t write CSS exactly as I would do
it, however as long as the work is of good quality
I have learned to just accept that, and not pick
over the work pointing out places where I would
have made a different choice. It is important that
you give your freelancers guidelines on any area
that you will not compromise - they are working
for you and should respect that - but you do

need to be able to take a hands-off approach to
some degree. If you hire a freelancer but then
spend the whole time micro-managing them you
will have spent the money but not gained
yourself the time back to do other work in
return.
Virtual PA Services and Outsourcing

Small Tasks
To make time for your side project you can

consider outsourcing work from other areas of
your business, or even other areas of your life. As
a married couple in business we have a cleaning
company come into our house twice a month to
do a thorough clean, including time consuming
jobs like mopping floors. As we work from
home, the house needing cleaning could be a
distraction, and time spent doing that is better
spent on the business. So we outsource it.

Many entrepreneurs recommend the use of
Virtual PA services. We are in the process of
moving house to a new area, and there are lots of
little tasks that need to be done - for example
finding a removal company and self storage unit.
I have an account with Fancy Hands and asked
them to do the research for me, calling round
companies and getting quotes. This saved me a
few hours and time on the phone, letting me
concentrate on work. This type of service works
really well for research type jobs, or jobs that
involve calling people - who may well not be
available and will call back when you are deep in
writing code - and can allow you to keep more
time available to work on your product. If you
think wider than simply outsourcing the work on
the product itself you can often find areas that
you can happily ask someone else to take on.
If you are having trouble thinking of what things

you could outsource, start keeping a log of

everything you do each day. At the end of the
week look at how long you spent on various
tasks, and consider whether it was a good use of
your time and whether someone else could have
dealt with that for you. Most people will find a
number of things that could be sent to one of
these services.
Being a Client
If you haven’t outsourced work before then

becoming a client for the first time is a strange
experience - especially if you have clients
yourself. Drew and I always worry that we might
be turning into the client from hell! However, the
fact that our freelancers seem to be happy to
work with us on numerous occasions makes me
think we aren’t too bad. Having run a services
business, we are aware of how it feels when
payments are delayed or our expertise is
constantly questioned, or we are not given

enough information to do a job well - and we try
to avoid those situations with the people we
work with.
I always pay people within the terms agreed, and

in fact usually by return as soon as I get their
invoice. If someone has done a great job for you,
the best way to say thank you is to pay them
quickly. As a business relying on freelancers this
will work in your favour too. If your freelancer
has various potential jobs they could accept but
knows that if they do your work, money will be
in the bank straight away, you are going to rise to
the top of the list!
If you have hired people with specialist

knowledge in an area - ask them their opinions -
don’t just treat them as the hired help. Your
freelancers can become part of your business and
encourage you to explore new possibilities for
your product or marketing materials. In

particular with the designers we work with, the
outside take we get on the product and
marketing site is truly valuable. We often think
we want a certain thing, but a fresh pair of eyes
and a fresh perspective quite often means the job
turns into something different. Freelancers need
to feel trusted to give you that input, if you can
create that trust then your product will benefit.
As mentioned earlier in this section, I try to back

off and trust freelancers to get on with the job
we have given them. If you feel you need to try
someone out - give them a small job first, rather
than something mission critical. However if you
have hired someone for their skills in a particular
area you need to trust them to do the work, and
accept they may make different choices to the
way you would have achieved a certain task.
Learning to let go, especially in areas you yourself
are competent in, is hard but it is how you will
get the best out of the people working for you.

Make sure that your freelancers have all of the
information they need to do the work and that
there is an open line of communication between
you and them. As a freelancer, it is very
frustrating to not know when client feedback will
come in, so try to respond quickly. If it is
unavoidable that feedback will be delayed then
let the freelancer know so they can at least get on
with some other work rather than waiting for
you.
All of the above can really be boiled down to

treating other people as we would like to be
treated. Value the people who bring their skills
and experience to your business, rather than
simply treating them as the hired help and you
will benefit from more than just code written or
design work created.

Take Action: Productivity
At the end of this chapter you should be starting
to think about how you can improve your
workflow and also which tasks you might be able
to outsource now or perhaps in the future when
your side project starts to bring in revenue.
1. Work out how much time you will be able

to devote to your side project each week -
be as realistic as possible.
2. Use the Cascading to-do list method to
create a plan to launch, using the time you
have available to create realistic chunks of
work.
3. Is there anything in your workflow or
development environment that could be
improved or that you know you need to
sort out? Make sure your to do list also
includes these - in the next couple of
weeks.

4. List the areas in which you know you
need external help, you should start to
find these people early as good freelancers
are usually busy freelancers.
5. List the areas where you are doing jobs
that you can do but could be easily
outsourced - remember that these don’t
need to be directly related to your project,
we’re trying to make time for the project.
If you are in a financial position to get
some of these off your plate start to look
for people or companies to do that.

Chapter 4: Pricing
When launching a product as a side project it can
be very easy to see any income as just a nice
extra. You are already able to survive on your
freelance income, or pay from your employment.
If the side project makes money it is a bonus, but
your house isn’t on the line if it doesn’t. That
may be true, however while in the first chapter of
this book I encourage you to think small, I now
want you to consider success way past the point
at which you would define success for your
product. What happens if this thing really takes
off?
Most of the things I will be talking about in later

chapters are scalable. If you find yourself with a
runaway success on your hands then you can
ramp up your infrastructure as needed or you can
bring in additional support personnel. However

you can only do that if those extra customers
represent enough additional revenue to be able
to afford to support them. It has never been so
easy to launch a product or service, as there are
plenty of other services we can use to put
together our infrastructure, however the costs of
using those services can mount up quickly as
photosharing service Everpix discovered in 2013.
They were forced to shut down despite gaining
55,000 users. The revenue from their 6,800 paid
subscribers wasn’t sufficient to cover the
Amazon hosting bill for storing all of the photos.
Ultimately with no cash available to pay a
$35,000 hosting bill, and no investors willing to
step in to save the unprofitable service, Everpix
had to close.
The story of Everpix is an extreme however it

would be quite easy for any of us to make a
similar mistake, and as bootstrappers the point at
which we would have to pull the plug would be

far sooner than a investment backed company
with a decent runway of cash. Make sure that you
do not price so cheaply, that a success is your
downfall.
The Pricing Model for Perch

Over four years on from launch, we still have the
same pricing model for our CMS that we started
out with, and given that we have been able to go
full time on the product that demonstrates the
model is working well. I’m going to talk through
our thinking when developing this model as it
highlights many of the areas that you need to
consider for your own products. You may well
come to different decisions based on your
product and audience, but the process is likely to
be similar.

Our Ideal Customer
From our very first internal discussions about

Perch we had an ideal customer in mind. The
idea for Perch came about because we were, as a
web development consultancy, typically brought
in by design agencies to develop projects that
involved work they were not confident in
delivering themselves. This tended to be things
like large custom CMS or e-commerce solutions.
Once working with an agency we would often
take on multiple projects for them. At some
point they would have projects too small in
scope for custom development but would still
want us to take them on. For these smaller
projects we wanted a CMS we could recommend
that would take the same care of the content
management experience and the front-end code
as our in-house framework did for large projects.
We had nothing to recommend and so started to
plan Perch.

Therefore, our ideal customer was a design
agency or freelancer web designer who cared
about markup.
Our Competition
At the time there were few commercial products

in this space. The only similar product that
seemed to have any traction was CushyCMS,
however this was a hosted CMS and from the
outset we knew we wanted to provide a self-
hosted solution.
A similar product in terms of being a

commercial, self-hosted CMS, was
ExpressionEngine. ExpressionEngine was
interesting to us as they had a lot of traction in
the same sort of market we were aiming to target.
This showed that a commercial, licensed CMS
could be attractive to people. ExpressionEngine
was not a direct competitor at the time, in fact

we saw Perch as being something that EE users
might use for their smaller projects, but it was
interesting due to having a similar model.
Of course we did have competition in terms of

free, open source products, the largest of this
being the behemoth that is WordPress. However
we did know that there was an ecosystem of
plugins for WordPress that were commercial,
showing that even WordPress users were not
averse to paying for something that saved them
time.
Our ideal customer was running a business and

we felt they would understand that if something
saves time, it justifies the price you pay for it.
Possible Pricing Models
For a self-hosted CMS we explored the following

possible methods of pricing the product.

A free core product with paid add-ons
One method of pricing software is to offer the

core product free to download and then to have
add-ons for the product that are commercially
licensed. A benefit of this model is that it enables
people to get their hands on the product without
paying for it, so they can try it out on simple
sites. This should encourage adoption by people,
especially those who are used to products that
are free.
The downside for a bootstrapped business is that

this approach can result in having a large amount
of users using your free product with no
intention of spending any money. The free users
will still take up your time supporting them, may
well demand features but only a small minority
will be happy to pay for them. As we wanted to
provide a developer API, we would also have
found ourselves in the situation of providing

people with the tools to build their own versions
of the add-ons we were asking people to
purchase.
A free or very inexpensive product with

commercial support
One option would be to distribute the product

for free or perhaps for a smaller charge, but only
offer support on a paid for basis. This is a model
often used for open source projects. The product
itself is free to download and use and you pay for
a support contract. I think this approach can
work if your ideal customer is large businesses.
Big businesses like support contracts, in fact they
will often only buy solutions that have them in
place.
However, paid for support can create a conflict

of interest. If support is free then it is in the
interest of the product developer to make it as

easy as possible to use, to create the best possible
documentation and help materials as each
support request costs time and therefore money.
It also creates tricky situations, especially with a
price per ticket raised model. If the customer has
hit up against a bug then they are going to be
more annoyed when they also have to use up a
support instance to talk to you about it.
As we will cover in a later chapter, support is also

a huge marketing opportunity. By making
support paid for you may lose some of that
ability to delight people, and it is where you
demonstrate how much you want to help
customers that you really get a benefit from
providing great support.

A free “light” version with a paid fully-
featured edition
A route taken by some other content

management systems was to offer a free light
version of the product with the fully featured or
professional version having a paid license. As
with the model of having a free core with paid
add ons, a major benefit of this model is that it
can help with adoption of the product. If people
use the free version and like it then the hope is
that they will need features of the paid version
and so upgrade.
The downside of having to support potentially a

large number of free users, is also the same. An
additional downside is that if you have these two
versions you have to start making decisions
based on revenue and not on what is best for the
product. A feature that might make complete
sense in both a light and full-featured version

might need to be missing from the light version
in order that it acts to encourage people to pay
for the full version.
A paid product with each add-on also being

paid for
It would also be possible to increase revenue by

selling to existing customers by having a price for
the product license and then selling each add-on
individually. This seems like a good way to
increase the amount of money each customer
represents. The downside for the customer
however is that pricing is less transparent. If mid-
project they need to add a feature from a
commercial add-on, they have the license cost to
consider in addition to the development time.
For the product, this model again raised an issue

in terms of making decisions for the sake of
revenue over making the product the best it can

possibly be. If we sell licenses for the product
and then for each add-on, it would make sense
from a business point of view to keep features
out of the core product - even if they made sense
to be there - and instead put them into an add-
on.
Our Choice
Ultimately we decided that opting for a very

simple, per license all inclusive cost would work
best for the product and for our ideal customer.
When you buy a Perch license you can download
and use any of our third party add-ons at no
extra cost, and support is free and unlimited.
The benefit to the customer is that they know

exactly what using Perch will cost - whether they
use the add-ons or not, or need support or not.
We felt that this ensured that the license cost for
any project would be clear from the start. There

is also a benefit to the product for this model. By
having one simple price, and charging for the
core product itself, we can make decisions about
which features go into and stay out of the core
product based on what is best for the product.
We feel that this serves both our customers and
our business well.
Deciding the per-license cost
With our pricing model decided we needed to

make a decision as to what this one simple price
would be. We knew that competitors were priced
anywhere from free to several hundred dollars.
We also knew that with a product aimed at
simpler sites, it was likely that these would be the
sites with lower budgets and we wanted to ensure
that we did not price the product out of those
budgets.

Keeping our ideal customer in mind we decided
that the per license cost should be no more than
an average hourly rate for a freelance designer,
therefore easily absorbed into a project if the
designer did not wish to bill their client
separately for the license. Thinking of the
customer who worked in a larger agency, we also
wanted the price to be less than they would need
sign off for. Many agencies allow people to
expense purchases needed to deliver a project,
under a certain amount. Over that amount other
people need to be involved in the decision.
The price needed to be all inclusive. It needed to

cover the costs of providing the product and
cover our time, so at the very least we could
spend time on the product and it would bring in
an equivalent amount to the same time spent on
client work. As a downloadable product we had
fewer costs of delivery - for example we had no
data storage costs - however there were a

number of fixed costs taken out of each
purchase:
• payment processing fees

• bank charges
• website and related services
• accountancy and bookkeeping
• Software and services such as our help
desk software, Xero.com for bookkeeping
and so on
Your decisions in pricing your own product will

be different from ours, you may well disagree
with some of our conclusions. What I want you
to take from this - as you start to develop your
own model - is that there should be thought
behind the model you choose. Simply deciding to
undercut the competition may create problems
for you in the future or mean that you leave
money on the table if your ideal customer is
different to those your competitor targets.

Step by Step Pricing
You can take a similar approach to pricing your
own product, the type of product you are selling
may give you more or fewer possibilities than we
had to consider but much of the process will be
the same. Working step by step through the
process of researching pricing models and price
points gives you time to consider the decisions
you are making, and to test them against your
requirements for the product and the market you
are aiming to enter.
Your Ideal Customer
Do you know who your product is for?

Throughout this book we will often be thinking
about this ideal customer, so the more complete
a picture you can build of them now will prove
useful. What is this person or company like? If
you are developing a new fitness application then

your customer is an individual - who are they?
Are they very price conscious or the sort of
person who is happy to pay for ground breaking
or simply well designed features? If you are
developing an invoicing app for small agencies,
what would the company who needs your app
look like? How many employees? What size of
projects? Who would normally sign off on the
new purchase or subscription for your app? How
many people will be involved in making that
decision?
In the previous chapter I advocated talking to

potential customers in order to validate your
idea. If you haven’t already done this then it
really is worth doing, the information you glean
from these conversations will really help you as
you start to think about pricing.

Whose money is being spent?
A key thing to consider when thinking about

your customer is to ascertain whether they are
spending their own money or whether they are
spending company money. At the most simple
this can be segmented in terms of customers
being consumers (B to C) or business (B to B).
However, in our experience it isn’t always as
simple as that. We sell our CMS mainly to
freelance designers and small to medium design
agencies. The design agencies see a purchase of a
CMS license as very much a business purchase,
absorbed into the cost of delivering the project.
Many freelancers however see paying for a CMS
as something that comes out of their profit for
the job. They act more like consumers and feel
that they are spending their money, not business
money, on the purchase.

The same is likely to be true of any other
solution aimed at self-employed people. It may
be on paper a business purchase, but many
freelancers do not have a strong differentiation
between personal and company money and will
see anything they need to purchase to do their
job as coming out of their own funds.
Understanding how your ideal customer views
the purchase can be very important.
Your Competitors
Unless you have come up with something truly

unique, you will have competition. Your direct
competitors are those who your ideal customer
will be considering in addition to your solution.
There may also be companies who initially look
like competitors but serve a very different ideal
customer. They can still be interesting to study
but beware of assuming that their pricing model
will work for your customers.

Make a list of your competitors and their pricing
models. Keep an eye on what they are doing in
terms of pricing other than their base price. For
example do they always seem to have some kind
of discount running? Do they offer their product
on bundle or discount sites at a special price? If
you put yourself into the shoes of that ideal
customer how easy is it to understand the pricing
model? Can you think of possible objections
from the ideal customer’s point of view?
You can use Twitter, discussion forums and

review sites to get a feel for how your
competitor’s pricing is working for their
customers. There will always be people
complaining about price, but are there specific
annoyances you can see? In our case seeing how
designers were unable to easily work out exactly
how much a project would cost by the time they
have purchased the individual licenses for a
number of different add ons to the core product

was a driver in our simple “everything included”
model.
You can get an idea of your competitors ideal

customer by looking at their marketing. Case
studies and customer profiles, or even just a list
of logos or company names of customers will
give you some idea of whether they are targeting
the same market as you. If they are obviously
operating in a different market then their pricing
model is of less relevance to you. However, if
your product covers some of the features of a
larger more expensive product but is aimed at an
audience who couldn’t afford the larger
competitor, you can draw favourable
comparisons with your product and pricing
compared to the bigger player.

Other Products for the same ideal
customer
It may be that your idea brings to the market a

product that already exists, but for a different
ideal customer. Or it could be that there are very
few similar products or you feel that the main
competitors are actually marketing their product
poorly. It can be worth looking at other products
that customers in the market you are targeting
use.
If you have a SaaS invoicing application for small

design agencies then you could look at the other
products these customers use. You can then
create a list of products and the pricing models ,
along with information about discounts or initial
free periods that are offered. This demonstrates
what your ideal customers are used to paying for
other services that they use to run their business
and so gives you an idea of what is realistic in

that market. A product will seem expensive to a
customer if it is a lot more than other things they
use for their business. That doesn’t mean you
can’t price higher - but you may need to work
harder at explaining the value to potential
customers.
Possible Pricing Models
In describing our process for deciding on the

way we would price our product I covered the
options for pricing a downloadable piece of
software. Due to the subscription nature of SaaS
you will have a different set of options to choose
from, and I’ll cover some of these here. As you
consider the different pricing models keep
referring back to that ideal customer. What are
the benefits to them of this model? What
potential objections might they raise?

Freemium
A freemium model offers a core product for free

and then premium features or increased usage
limits at a cost. Products that operate in this way
include Evernote, Dropbox and MailChimp.
Freemium makes sense if you want to encourage
a large number of users in to try your product
and believe that they will then be happy to pay
for the extra features. However you may well
find yourself simply supporting a lot of free users
who are not interested in the paid option. For
most side projects and bootstrapped companies a
freemium model is not an option as without
initial investment to support the free users while
you try and encourage them through to paid
plans you are unlikely to have the available cash
to survive.

Tiered subscription pricing
A freemium model really just means that you

have created a free initial tier of a tiered
subscription model. Tiered subscriptions are the
most commonly seen model used by SaaS
companies, with tiers segmented in a way that
reflects the different usage of customers who fit
into that tier. How the tiers are segmented
depends on the type of service that you are
offering, and the requirements and concerns of
your ideal customer. A mailing list provider such
as MailChimp has a tiered model based on size of
list and therefore number of emails sent, this
model reflects resource usage. It is easy to justify
the price of the more expensive plans both from
a resource point of view and by the fact that a
customer sending to a large list is presumably
making more revenue via those activities than a
person with a list of 500.

37 signals have priced their flagship product
Basecamp on the number of projects that you
might create, with a data storage limit for files
linked to that. Again this is linked to the size of
business using the account. If your agency has
100 concurrently running projects then you
should have revenue that makes the $100 per
month Basecamp plan seem good value. A new
agency run by a sole proprietor can pay $20 per
month and is able to run 10 projects
concurrently. For any business these pricing
models make perfect sense, if you use more, you
pay more. They can easily be justified as an
expense and any increase is linked to the growth
of the business.
Per seat pricing
A method of pricing, sometimes used in

combination with feature based tiers is pricing
per seat. How many people can log into and use

the account? This is a common model for help
desk software and again makes good sense. A
larger company is likely to have a number of
support personnel, a new startup might just have
the founder. Allowing customers to pay per user
of the software helps them to see the value and
be confident that they are not paying for more
users than they require. If you are a solo founder
signing up for a helpdesk SaaS and the lowest tier
includes up to ten users, you might feel that this
is capacity you are paying for that you will never
grow into. Knowing that you are currently just
paying for your access, and if you need to add a
team member you will then also pay for theirs
means you know the cost implications in terms
of the software of adding a member.
Pay-as-you-go
The mailing list service Campaign Monitor offers

a pay-as-you-go plan for sending out emails. You

create your account for free, build a list and then
pay per campaign for the number of emails you
wish to send. For any service that involves
consumption of resources then this type of
model can work well, and means that customers
do not feel that they are paying a monthly
subscription for something that they use
occasionally. It may also encourage customers to
try out the service, without the need for a
completely free trial. The customer is not tied in,
they can try the service once using a small
number of credits and have no obligation to
continue to use it if it does not work out.
If your product operates purely in a pay-as-you-

go fashion then you will need to work hard to
keep customers engaged and interested in
coming back as you are only paid if they are
using the service.

Combining models
Some products offer models that combine some

of the above models, or they offer customers the
ability to choose from two different models
depending on which best suits them at the time.
At the time of writing both MailChimp and
Campaign Monitor allow customers to choose
from a monthly subscription with list size limits
or a form of pay-as-you-go pricing, MailChimp
users can buy credits, Campaign Monitor users
can pay per campaign as previously described.
Providing options in this way does complicate
your basic pricing strategy but may be helpful if
you have customers who want to use your
service in very different ways.
Other services include a low monthly

subscription element plus per usage pricing.
Customers of short term car hire company
Zipcar pay a low monthly or annual fee to

become a member of the service, and then an
hourly or daily rate when they are actually using a
car. This seems to make sense as a model that
reflects the basic running costs of the service,
plus then the actual cost of hiring a car for a
period of time.
Keeping it simple
The segmented pricing model has now become

so common in SaaS that some companies are
making a feature of not pricing in this way. At
the time of writing, if I click the Pricing link on
the site for customer support SaaS Snappy, I get
an overlay stating “$10 per user per month. No
add-ons. No surprises.” I don’t have to figure
out which plan is best for me, I know that I will
pay $10 multiplied by the number of users. This
is very reminiscent of what we do with Perch,
and both Snappy and Perch seek to be a simple
option in a marketplace of competitors who

market their products based on complex
features. It can help to set the tone of your
product right from the start if the pricing model
is also straightforward.
A note about Unlimited Plans
At Perch we are often asked if we will offer a

plan where the customer can pay once and then
create “unlimited” websites for their customers.
Some SaaS products, including Basecamp at the
time of writing, offer an expensive but unlimited
plan. Whichever pricing model you select, if your
product or service is aimed at customers who will
use it to provide a service of their own you will
be asked for this unlimited plan.
Think carefully before offering such a plan, as

once offered it is hard to take back, if it turns out
to be unprofitable. If plans have limits you can
ensure that each customer pays their way,

unlimited plans essentially create a top limit of
what you can earn from a single customer. Even
if this plan has a very high cost, the customer
who goes for it is probably going to be one who
could easily afford to pay for your regular plans
to get the upper limits or numbers of licenses
that they need.
There is an additional reason why we didn’t go

for the unlimited plan or “site license” for Perch.
Once we have a customer who has bought such
a plan there is no incentive to keep that customer
coming back for more licenses. They have paid
us as much as they are ever going to pay us, even
if we never improve the product again. We can
add features and improve the product but it
won’t reflect in revenue generated from some of
our best customers - they have already purchased
their unlimited license. Our per site pricing
means that we are only ever as good as a
customer’s last install, if we drop the ball then

the customers will go elsewhere so it keeps us on
our toes and with our focus in the right place -
improving the product for our customers.
Your Costs
You may think you have come up with the

perfect pricing model for your software or
service, however the cost per download, or per
billing cycle needs to ensure that you can become
profitable. Profit comes after you have paid
everything you need to provide the service, so
you need to ensure that your basic cost
realistically covers everything needed to create
and deliver your product.
Some costs are front loaded. You will need to

pay out for some things before you can get your
first paying customer. For a downloadable
product such as an e-book or small plugin for
another product these costs can be very low. If

you use a service to take payment and deliver
your product that takes a cut of the payment
rather than a monthly fee, you may be looking at
fairly insignificant up front costs for hosting a
marketing site. However for SaaS products, you
need to have your infrastructure in place before
you start to make any money. It will take a
certain number of customers before you hit
profitability. If you know what your up front
costs are then you can start to play with numbers
for your basic pricing and work out how long it
will be before you are into profit. You need to
know this. If savings, income from your other
business or your job are going to subsidise the
product until it starts to make money, there will
be a finite amount of time before you either run
out of cash or start to see the project as being a
drain on resources.
Keep a simple spreadsheet of costs as you

develop your product and infrastructure. Add to

it as you make decisions about services to use.
Continually check that your pricing model works
with all of these costs taken into account.
Choosing a Price
Having read this chapter you should be coming

closer to making a decision about the pricing
model to use, and have a way to calculate what
you will be charging customers. Ultimately you
may find that your initial “gut feeling” is right -
especially if you know the sector that your ideal
customer is part of well. However considering all
of the possible options ensures that you don’t
make a quick judgement based on that feeling -
in particular where things like unlimited plans
that are hard to revoke are concerned.
The actual price for the product, or for each tier

of a segmented price plan is the final piece of the
puzzle, and once you know your ideal customer,

the pricing of competitors, similar products
aimed at that same customer and crucially your
costs to deliver the product or service deciding
the launch pricing should be quite
straightforward.
In the rest of this chapter I will introduce some

other elements of taking payment that relate to
pricing. Such as the costs of customer
acquisition, special offers, local taxes and
payment in multiple currencies.
Customer Acquisition and

Lifetime Value
While acquiring customers may not be an actual
running cost of your product, if you don’t have
any customers you don’t have a business. For
most businesses some form of paid customer
acquisition through advertising or sponsorship

will be necessary. The venture capital backed
startups often throw a huge amount of money
into advertising and sponsoring events to raise
awareness of their product, and hopefully
encourage signups. That route is unlikely to be
possible for your bootstrapped side project,
however you may want to use some paid
advertising, or sponsorship such as we will
discuss towards the end of the book.
When considering the costs of customer

acquisition you need to take into account the
lifetime value, or “LTV”, of that customer. This
is the amount of revenue they are likely to bring
in once acquired. A very simple example is
detailed would be as follows:
I place an ad on a popular web design tutorial

site for $200 per month. From that ad in January
4 customers sign up making the cost of acquiring
those customers $50 per customer. The

subscription that they sign up for is $25 per
month therefore it is only after two months that
I make back the cost of getting those customers,
however if on average customers remain
subscribed for more than two months and these
customers follow that same pattern, after two
months the revenue is profit.
This is obviously a very simplistic example, and

assumes that you know how long a user remains
a paying customer, these are things you will have
little idea of at the start. What this is really about
is the age-old truth that sometimes you need to
spend money to make money. You need to pay
for advertising even though you might not see a
return for a few months.
Unless you are creating a product that requires a

lot of users to become useful - for example
something that requires a social element - then
for a side project you can often wait until you

have more information to hand before starting to
experiment with paid customer acquisition. In
particular if you are releasing a product into a
market where you are already known, and have
been following the advice later in the book to
build a up a pre-launch list, you can often get a
long way just via word of mouth. As revenue
starts to come in, you can begin to use some of
that to try and develop your market outside the
people you can easily reach yourself or through
your networks.
Card up-front or after trial?

For SaaS businesses, offering a trial prior to
payment for the first billing period, you will need
to decide whether to request the customer’s card
up front - but not charge until the end of the trial
or allow them to sign up for a trial with no card
needed and then email them as the trial ends to
ask for details.

The first method - card up front - is likely to
result in fewer trials. Having to enter a credit
card means that the customer needs to remember
to go back and cancel the account if they decide
not to continue, and it creates a higher barrier to
entry. However this can be a good thing in terms
of trial accounts converting. Users who are
willing to enter card details to try out your
service are more likely to be really interested and
not just wanting to have a poke around this latest
thing. If you need to invest time onboarding
customers then the card up front method will
mean that you are spending time on people who
at least were interested enough to give you
payment details.
Asking for a credit card up front however does

require that the user has a level of trust in your
and your product right from the start of your
relationship. If the customer is encountering the
product cold, sees that it might be what they

need, but then has to commit to entering their
card details just to take a look they may well back
off at that point - in particular if there are a lot of
competitors to take a look at first. In the case of
a crowded market, a customer may well have a
shortlist of a large number of products. Having a
higher barrier to entry may simply push you
down the list and the potential customer may
stay with a competitor even if - had they tried
your product - it would have been a better fit.
Which method will work best for your particular

product and ideal customer is something you
would need to test for yourself, there is certainly
no single right answer here.
Special Offers and Discounts

Using special offers, discounts and sales to
encourage customers to buy your product can be
a great way to get people to make the leap

however you need to ensure that you are still
going to make some profit on customers who are
paying a reduced price for your product. How
easily you can discount the product will depend
on the type of product you are offering.
For Perch we have discovered that even a small

discount encourages people to buy - this includes
regular customers as well as new customers.
When we run a sale we typically do a 20%
discount. We will see regular customers buying a
number of licenses - stocking up for their next
project - however we also see an upturn in new
customers, people encouraged to try the product
for the first time due to the discount. These
discounts seem to work most effectively when
offered for a short period of 1 to 3 days. Much
longer and people see the offer, but think that
they will take advantage later, and then forget to
do so.

One Time Purchases
For products that are a one off purchase - for

example an e-book - then the lifetime value of
the customer is that one-off purchase. If you
develop more products that target the same ideal
customer, then it is possible that you could get
another purchase from them in future, however
you want to ensure that even at a discount each
sale is valuable to you. For many one-time
purchases the profit margin is fairly high, as there
are not many costs that need to be accounted for
in terms of infrastructure. Therefore
experimenting with special offer codes or
discounting the product for a time will still make
you money, and is likely to encourage people to
buy who would not do so at the full price. It is
easy with special offers to imagine that you are
losing the revenue that you have discounted the
product by, however in our experience these

sales make little difference to overall trends but
we do gain customers each time we run one.
Software as a Service
SaaS businesses are better placed to use special

offers to encourage customers to try their
product. It doesn’t matter what it costs you to
acquire the customer - either in direct payments
out to advertising or in loss of revenue from
offering a discount - as long as you can be
reasonably confident that the lifetime value of
that customer will be more. For SaaS products
offering a free introductory period is normal,
however you might offer an extra period at a
lower rate or even a lower rate for the life of the
account. You can experiment with discounts to
help with customer acquisition. For example if
you are to sponsor a podcast, you could give a
special code for listeners to use to double their
trial period time or discount the plan. This will

not only help encourage the initial sale but gives
you a way to track how well that advertising
channel is performing.
Beware the “always on offer” trap
I don’t know if this is a UK-specific thing, but

here furniture stores are something of a standing
joke as they always seem to have a sale on,
constantly running adverts on TV about their
special offers. You don’t want your product to be
always on sale. By doing so you lose the benefit
of doing very occasional, limited offers that
people know they need to take up as there will
not be another opportunity soon. You also are in
danger of making customers feel they have
missed out if they fail to locate an offer code, so
they buy the product but have some sense of
feeling they have probably paid over the odds.

The same is true of having a discount code box
at checkout, and we have fallen into that trap at
Perch. We have used single use discount codes as
part of our promotional activities when
sponsoring conferences, or just when at events
and meeting people. We used Moo cards and
generated these discount codes. We then needed
a method of allowing customers to enter the
codes at checkout and so we added a discount
code box to the form. That box is also used on
the occasions we run a special offer. The
problem then is that customers who come to the
site, see the box and think there there must be a
special offer somewhere if they just looked for it.
So we see people in our tracking, visiting all of
the online coupon and voucher code sites to see
if they can find a valid coupon code. All they
usually find are long expired codes from previous
sales. If they then go on to buy a license they
probably feel at the very least as if they have
wasted their time, but I would imagine they also

feel they have in some way paid more than they
should have, because they couldn’t find a code.
We don’t normally have an offer running so in

our current rebuild of the payment process we
are moving that offer code box and instead will
use a special URL to send users to if they have a
code. For people with existing cards - if they
can’t see a way to enter their code they will
contact us and we can point them to the correct
URL.
One Currency or Multiple

Currencies
When we launched Perch we priced the product
in GBP as we are a UK-based company. What
we didn’t appreciate is that this resulted in fairly
high transaction costs for people in the USA
paying with their credit cards. This meant that

the basic cost of the product was high for
customers who didn’t have a card or PayPal
account with a GBP balance.
In retrospect, opting for a single currency, it may

have been better to price the product simply in
dollars as people worldwide tend to understand
the value of the dollar against their own currency
and are well used to paying in it. I don’t think
twice about signing up for a service or buying a
product in dollars as so many of the tools and
services that we use are based out of the USA.
When deciding how to price this book I decided
to keep things simple pricing it only in US
Dollars.
If you decide to offer payment in multiple

currencies - as we now do for Perch - you need
to make a decision as to whether you will have a
fixed price in your base currency and then do a
currency conversion at time of purchase before

taking payment in the customer’s selected
currency or whether you will fix the prices in
each currency that you offer and shoulder any
fluctuations in exchange rate yourself. The choice
is likely to depend on both the audience and
value of payments. We decided, with Perch being
a low cost product and wanting people to know
exactly what they would pay, that we would fix
the prices. So depending on exchange rates we
sometimes get a little more than the GBP price
for Euro or US Dollars and sometimes a little
less, however at the price point we are at these
fluctuations tend to amount to less than a dollar.
If we were a higher cost product fluctuations
could cost us significant amounts and so I would
have been more likely to decide to keep our base
cost in our home currency and simple display
indicative prices - perhaps using an exchange rate
API in order that they were relatively accurate
each day.

If you are fixing prices for each currency you
should of course be aware of exchange rate
fluctuations and if you discover that a currency is
now charged a great deal more or less than the
price in your home currency adjust the pricing
accordingly.
VAT and Local Taxes

A final mention in this chapter on pricing is that
you may need to consider rules regarding taxes
that need to be charged to some or all of your
customers. In the UK and Europe we have VAT
and in the USA there are rules around state taxes
that may apply. As an international book I will
not attempt to discuss all taxation models but
you do need to ensure that you have correctly
researched and included these taxes where
appropriate.

VAT in the UK and Europe is particularly
notable for a business already trading, as if you
are under a certain threshold of revenue you do
not need to charge VAT. In the UK that
threshold is quite high so, for example, I am
selling this book as an individual “sole trader”
rather than through my limited company. Unless
it becomes wildly successful and generates more
than £79,000 (along with other writing and
personal income) I do not need to become VAT
Registered and therefore do not need to charge
VAT on each transaction. However, had I
decided to write this as a project of
edgeofmyseat.com, a VAT Registered company,
I would have needed to charge VAT on each
transaction as the company revenue is over that
threshold and therefore has to be VAT
registered. This is an area where decisions made
in terms of whether to set up a new company for
a product or trade under your existing company
can have repercussions. Perch has always been

sold as a product of edgeofmyseat.com and so
we had to charge VAT to UK and European
customers right from the start.
Check the taxes you may be liable for early on in

your planning. They will have implications in
terms of customer flow through the checkout
process and even in terms of payment solutions
you can use. Run your thoughts by your
accountant or tax advisor if you have one, or at
the very least contact your local tax office and
check that your understanding of what you need
to pay and when is correct.
Take Action: Pricing Models

The length of this chapter demonstrates the
potential complexity around choosing a pricing
model and price for your product or service. I’d
like you to start to research possible options right

now, as you can then ensure that they hold up as
you firm up the rest of your plans.
Decide who your ideal customer is. Get as

detailed as you can into the type of person or
business that they are.
List the possible pricing models you could use

for your product.
Research your competitors and ask the following

questions:
• What pricing model are they using?

• Do they serve the same ideal customer as
you?
• If the customer is the same as yours, are
you able to see if the pricing model is
working well for customers? Twitter and
Facebook can be helpful here, what are
people saying?

Research other products or services that target
your ideal customer. Ask yourself:
• What pricing model are they using?

• Do customers seem happy with this
model?
Begin a list or spreadsheet detailing the costs of

selling your product. You might not have a final
list yet, and we’ll be covering many potential
costs in detail throughout this book, but you may
already be aware of costs specific to your
product. Every time you make a decision that
involves spending money either up front or in an
ongoing way make sure it gets added to the list.
Include any costs of customer acquisition if you
know that you will need to advertise or otherwise
pay for this.
If you do not understand the implications of

taking payment for your product in terms of

taxes, find this out now. It will be important as
you move on to develop an infrastructure for
taking payments.

Chapter 5: The
practicalities of selling
products online
Even a very simple product will require some
infrastructure around it - in order to market the
product, take payment and see whether your
marketing tactics are converting. In this chapter
we will consider our options in these areas.
Taking Payments
To sell your product online you need to have a
method of taking payment in place. There are a
huge number of options available and providers
vary depending on the country you live in.
Therefore rather than trying to create a complete
list here I will describe the different types of

payment methods available to you, and some of
the international providers, to give you a starting
point for your own research.
Merchant Account and PSP
I am going to start with the “traditional”

payments route of a merchant account at an
acquiring bank plus a payment processor
(sometimes referred to as a PSP - Payment
Service Provider). Fewer startups and small
businesses are using this route today, due to the
difficulties involved in getting a merchant
account and the availability of newer payment
services. That said, all of these newer services are
ultimately backed by acquiring banks and there
are things about payments that refer back to this
traditional setup and are worth understanding.

The Merchant Account
To process card payments you need an account

at an acquiring bank, these are usually known as
merchant accounts. Your business bank may also
offer merchant accounts but you don’t need to
have an account at the same bank you use for
your banking. The job of the merchant account
is to process credit card payments through to
your actual bank account. It is the merchant
account that gives you the ability to take card
payments.
When you sign up for a merchant account you

will need to let them know that you want to take
online payments and, unless there is some
physical aspect to your business you will
probably tell them you are online only and don’t
need a PDQ machine such as you would have in
a physical store. You will be offered a rate for the
different types of cards you might want to

process, this will be a percentage of the
transaction value. Debit cards are treated
differently to credit cards, and the different types
of credit cards attract different rates. There may
also be a monthly fixed cost in addition to the
per transaction rates that you will need to pay
even if you don’t make any transactions that
month.
Once your account is taking payments money

will be processed through to your current
account in a batch, usually containing all of the
payments for that day. Depending on the
acquirer the transaction fees will either be
dedicated or you will be billed for them
separately at the end of the period.
The merchant account itself does not give you an

interface to take payments online, although they
may also have such a service available it is a
separate thing to the merchant account itself.

Therefore when setting up your account at the
acquiring bank they will usually want to know
which payment gateway or PSP you are going to
use.
The PSP
The Payment Service Provider (PSP) or payment

gateway is essentially a replacement for the
machine in a store or restaurant that reads your
card and processes the payment through to the
acquiring bank. Many banks offer their own PSP
service, and will give you the opportunity to sign
up for that when you set up your merchant
account. However you are generally not tied to
using the bank PSP service and can shop around,
comparing services and pricing.
The PSP is who you will be interacting with

when developing your payment system so you
should check how easy they will be to work with

technically in addition to comparing the services
on price. You should also look at the reporting
that is available from the PSP, and the UI that
you will need to use to process refunds and
perform any transactions on behalf of customers.
Integrating with a PSP
There are roughly two methods by which you

can take card details via a PSP. You can either
take the card payment on your own website and
transmit it securely over SSL using the PSP’s API
or you can use a payment page on the PSP,
which means that your customer will need to
leave your site to actually enter their card details
and then return to your site at the end of the
process - much as you do when paying for
something using PayPal.
The first method - transmitting payment details

via an API - does have the benefit of leaving the

process under your control. Rather than your
customers seeing a rather ugly PSP screen when
it comes to entering payment, you can ensure the
experience is as good as the rest of your site. The
downside of using this method is that you have
more liability in terms of ensuring the customer
card details are secure while being taken on your
server and transmitted via the API. You will need
to comply with more stringent regulations, which
I will cover later in this chapter.
Using the PSP payment page whether the

customer is transferred there or the page is
displayed in an iframe means that you have less
liability for card details as you never have any
access to those details at any point in the process.
Technically you will usually build up the order on
your website, creating a customer account and
that at the final step of checkout transfer the
customer and all of their order details to the PSP
payment page. The customer will make payment

and then will be handed back to your server
along with information about the transaction
status - so you can enable download of the
product or sign them up to your service.
While using a payment page does mean that part

of your order process is out of your hands, it
does mean that any changes in payment
regulations are handled by the PSP and you do
not need to change your code to handle it. For
example when banks started to levy high
transaction charges for customers who were not
operating the Verified by Visa scheme, we were
able to simply switch that on by letting the PSP
know. Had we developed our own integration
with the API we would have needed to write the
code to handle Verified by Visa and the
redirection to the bank page.
We use the payment page method for customers

paying for our product, and it works well. As a

small company we would prefer not to have the
liability of keeping customer card data secure and
the PSP API gives us enough information after
payment to be able to mark the customer order
as paid and log the transaction in Xero, our
accounting package. Customers are used to going
out to a third party pages at this point and in
some ways, a savvy customer may be more
confident if they can see they are entering details
on a bank payment page rather than on the
website of a company they do not really know
much about.
“All in one” services
Some acquiring banks and some PSPs offer

bundled solutions that combine the merchant
account and PSP in one package. Some of these
are very well combined and save you having bills
and login details in two places, others work on
the basis that the bank or PSP sort out the other

part of the puzzle for you. Compare the terms
and pricing of the bundled service against
selecting these two parts separately as the
convenience can sometimes mean that you end
up paying more per transaction.
Recurring Payments
The majority of PSPs these days have some kind

of token system. A token system gives you the
ability to charge a customer’s card again without
needing to store the card details yourself. If you
use the token system, once the customer has
indicated they are happy for you to store their
details, the PSP gives you a token which
identifies the customer card. The PSP stores the
sensitive card data. If you want to take another
payment from this card you present the PSP with
the customer token.

The token system enables “one click purchase”
and is useful if customers make lots of small
purchases for different things on your site, or
need to top up credits to use a service. If you just
want to enable monthly billing of the customer
card then you probably need to ensure that your
merchant account allows continuous authority
payments. Some acquiring banks offer these
accounts as standard, others you will have to
request this facility specifically when setting up
your account. Your PSP will then provide a
method via they payment page or API for the
customer to set up a continuous authority
agreement on their card which will continue until
ended. You will also need to ensure that you
have a method developed for customers to close
their account and stop those payments from
being taken.

Rolling Reserves
When setting up your merchant account with an

acquiring bank you will be offered terms. These
will be based on the type of company you are,
the sort of products you are selling, the value and
number of expected transactions, a credit check
of the company and/or owners and the length of
time you ave been in business. All of this helps
to establish the risk that you pose to the bank.
The terms will partly reflect in the percentage the

bank will take for each transaction but may also
include a rolling reserve being applied to your
account. A rolling reserve is an amount of money
held by the bank to cover potential chargebacks -
people requesting their money back after paying.
Some types of transactions are deemed more
risky than others. For example, events are seen as
quite risky because if the event is cancelled or
turns out to be not as advertised and the event

company does not quickly offer refunds a large
number of customers might put a chargeback
through on their card. If the customer does not
have enough money to cover the chargebacks the
bank would lose out.
A rolling reserve is not too much of a problem

once you are making regular money, however if
you do have a rolling reserve in place you will
need to remember that some of your money will
be tied up in that and not accessible to you. You
can usually apply to have the rolling reserve
reduced or removed once your account has been
operating for some months. If you have a year of
transaction history with no or very few
chargebacks then the bank may be happy to
reassess your risk based on that history, and
remove the reserve.

Chargebacks
As you are probably already aware as a consumer

the card companies guarantee card payments. If
you purchase something that is not as advertised
from a company, or the company becomes
insolvent and cannot fulfil your order and you
are unable to get a refund, the card company will
give you your money back and they will pursue
the merchant for the money. They do this by
issuing a chargeback against the merchant.
Being subject to a large number of these

chargebacks is a red flag to your acquiring bank,
as it would be expected that if a customer has a
valid refund request they would contact you as
the merchant and you would process that refund
yourself rather than waiting for them to demand
the payment back via their card issuer. Therefore
it is in your interests to ensure that chargebacks
are as infrequent as possible and that customers

understand what you are charging them for and
when, in order that they don’t mistakenly think
your card charge is someone using the card
fraudulently.
Your acquiring bank and PSP will usually have

information as to what you need to have on your
site to inform customers of their rights.
Depending on the country you are registered in
and the type of product you are selling there may
be legal requirements to offer refunds, so you
should ensure you know what customers are
entitled to so that you can act in accordance with
those rules.
If a customer makes a chargeback request against

you but you can demonstrate that you have acted
properly then the money will often be refunded
to you. For example if you sell non-refundable
software, or a customised product that is
allowably non-refundable in your country, and

can show the bank that the information about no
refunds was presented to the customer, then the
issue may well be resolved in your favour. So it is
very much in your interests to ensure that you
have done everything by the book - even if it
does mean reading and understanding some very
dull documentation to get there.
Ensure your customer knows who the credit

card charge is from
A very common reason for chargebacks is where

a customer does not recognise the company on
their statement. If you are an existing company it
may be that your product name is different to the
company name and so a customer or their
accountant thinks the transaction is something
they did not authorise. Make sure that all your
communication states the company name
somewhere - for example we put “Perch is a
product from edgeofmyseat.com” - on official

things like invoices. Ensure that there are easy
ways for people to contact you if they are
searching for the company name after seeing it
on a statement.
Multi-Currency
I mentioned multi-currency in the chapter on

pricing models. If you have a merchant account
and PSP then you will usually need to specify the
currencies you want to accept payments in. Most
of the acquirers I have encountered in the UK
offer a standard merchant account in GBP, my
home currency, with the option of a multi
currency merchant number which can accept
various different currencies. Your PSP should be
able to accept payments in any currencies that
you have set up with your acquiring bank, you
just need to let them know.

The PCI DSS
If you are accepting credit card payments, and

especially you have a traditional merchant
account and PSP set up, you will need to become
familiar with the Payment Card Industry Data
Security Standard - usually referred to as the PCI
DSS. This is a set of requirements that aim to
safeguard customer card data and prevent people
storing and transmitting card numbers in an
insecure manner.
Whatever you may think of the PCI DSS, your

acquiring bank will want to ensure that you are
compliant with these regulations. If you are using
a payment page solution, where you do not store
or even transmit card details to your PSP, and do
not take card details any other way - such as in
person or over the phone - then you only need to
indicate this fact by way of the self assessment
SAQ A. For some time I have been completing

my own form, this year my acquiring bank are
refuse to accept self-certified forms and we now
have to go via their system to become compliant.
If you do transmit card data by way of an API

integration with your PSP then you will be
subject to higher levels of compliance, possibility
including quarterly security scans. My advice to
any bootstrapper would be to avoid getting into
that situation unless it is business critical that you
avoid the payment page scenario. Complying
with the PCI DSS requirements will mean
ensuring that you or your host fully understand
what needs to be done to pass the quarterly scan,
as well as paying the company who will perform
the scan for you.
PayPal
For many years PayPal was the main alternative

for people who couldn’t, or didn’t want to have a

merchant account. The main advantage of PayPal
being that it is easy to create an account and get
started taking payments - with no initial setup
costs. This makes it attractive if you are just
testing the waters with your product. Technically
you can integrate PayPal just like a PSP payment
page, using the PayPal IPN to perform a callback
to your system to indicate that payment has been
taken successfully. PayPal also makes accepting
payments in multiple currencies easy for the new
business owner.
We use PayPal as one payment option for Perch,

and have had no problems with PayPal, however
where people do seem to have problems is due
to the manner in which PayPal deals with
chargebacks and rolling reserves. This really is
the downside of any service with a low barrier to
getting started. When you set up an account with
an acquiring bank they do a lot of investigation
into you before offering terms - so they are

unlikely to suddenly change these terms without
warning you. PayPal know nothing about you
and your business when you start accepting
payments, and it is here that the problem lies.
Just like any acquirer, PayPal need to honour

chargebacks and also have their own dispute
system whereby customers can ask PayPal to
investigate transactions. PayPal themselves also
sometimes flag a transaction as somehow
suspect. The first you will hear of any such
investigation will be a hold being placed on the
money in your account. At this point the money
is still with PayPal - neither you nor the customer
has access to it. If the hold is due to a complaint
from a customer rather than a suspicious
transaction you will then enter a process where
either you work out the issue with the customer
or PayPal will step in and make a decision as to
whether the customer is justified.

PayPal advertises a “Seller Protection policy”
however you should note that, “The Seller
Protection policy does not cover the sale of
services, intangible or digital goods or prohibited
items.” - PayPal Seller Protection. Seller
protection really only applies if you are selling
and shipping a physical product. For sellers of
digital goods you need to ensure that your
policies are clearly stated on your website in
order that if a dispute is raised you can
demonstrate to PayPal that the buyer agreed to
your terms before downloading the product. This
is particularly important if you do have a no-
refunds policy. An actual chargeback operates
just like a chargeback for a payment taken by
your merchant account, in this case it is the
credit card company who is investigating, so
once again having proper information can save
you from the case being decided against you.

Any dispute that ends up in the PayPal system
enters a process that can seem very opaque, with
PayPal having the ability to make a decision and
remove cash from your account for a product
already downloaded and being used by a
customer. Our experience is that it is well worth
getting on the phone to PayPal and discussing
the issue with them, you will still need to go
through the online process but I’ve found their
support actually very helpful. On a non-
refundable product in over four years, with many
thousands of transactions, we have had only
three disputes raised and two of those were
decided in our favour. The other appeared to be
genuine fraud. So it is not the case, as is
sometimes suggested, that PayPal will grant the
dispute to the side of the customer, however in
order to get that decision I did need to be able to
demonstrate that we had all of our terms
displayed clearly throughout our purchase
process.

The other problem with PayPal that you will hear
about is a situation where they suddenly decide
to hold onto a large sum of your money, without
warning. This behaviour has caught out a
number of conference organisers, who then
found that the money they needed to pay hotels
and venues was trapped in PayPal until after the
event had taken place. Any business that might
suddenly start to take a large amount of
payments - perhaps due to a successful launch -
is in danger of being caught in this way. If you
understand the concept of a rolling reserve, as
discussed earlier in this chapter then you can see
what PayPal are doing. They are implementing,
retrospectively, a rolling or minimum balance
reserve in order to protect themselves from
chargebacks. An acquiring bank is far less likely
to do this out of the blue because they will have
assessed your risk before granting you the
account.

Contacting PayPal ahead of any large spike in
sales is often recommended. If you are gearing
up for a big launch and expect a sudden rush of
traffic through a PayPal account that is new or
has only had a small number of payments in the
past this is a sensible step to take. However my
suggestion would be to not leave large sums of
money sat in your PayPal account. Withdrawing
your money regularly can at least protect you
from PayPal locking money already taken away
from you however, as with any payment
provider, you are at the mercy of the terms they
want to offer you. Ultimately the best protection
is to make sure you can quickly switch to another
provider if one starts to make it difficult to do
business.
Stripe
It would be impossible to talk about payment

solutions in 2014 without mentioning Stripe.

Stripe is an innovative payments company, who
have changed the landscape of payments
acceptance over the last couple of years with
their developer friendly API and documentation,
and by creating a service that is as easy to get
started with as PayPal but seems to offer more
transparency.
Stripe acts as both a payment gateway and

merchant account for your business - allowing
you to take payments and processing the money
through to your bank account. You can use
Stripe to accept payment in a currency other than
your own or in multiple currencies. They have a
very clear pricing policy, taking a fixed amount
plus a percentage of each transaction - which is
comparable to other solutions.
Stripe operate a 7 day rolling payment structure,

essentially a rolling reserve. Therefore any
payments that are taken on March 1st would be

sent to your bank account on March 8th with
Stripe fees deducted. In comparison to a
merchant account and PSP setup, where you can
find charges taken in two different places, this
makes reporting payments nice and
straightforward.
You will need to take care that customers are not

making chargebacks against payments when
using Stripe - as with any other payment method.
Unlike PayPal I have not heard any horror stories
of Stripe suddenly changing the terms on a
customer without warning, however they do
reserve the right in the terms of service to do so.
The most likely reason for any payment solution
to make a decision to withhold funds from you is
if you are getting a lot of chargebacks and
complaints - and there is a lot that you can do to
stop that happening as described earlier in this
chapter.

Stripe is a PCI Level 1 Service Provider, meaning
that they have been audited and their process and
servers comply with the PCI DSS. Any payment
provider that you use to handle your card
processing should be Level 1 compliant. Their
documentation states that if you use their service
correctly you do not have to do anything else to
comply with the PCI DSS.
“ Anyone accepting credit card payments must

be PCI compliant—but with Stripe, it’s easy:
• Serve your payment page over SSL, i.e.,

the page's web address should begin with
"https", not "http”,
• Use Stripe.js as the only means by which
you accept payment information and
transmit it directly to Stripe's servers.
By taking these steps, you completely avoid

handling sensitive card data, and keep your

systems out of PCI scope.“ - Stripe, PCI
Compliance.
I asked Stripe for some more information about

this as traditional merchant accounts will
normally require that you complete the SAQ A,
even if you are using a payment page and
therefore not storing or transmitting card data.
The response was that essentially when you sign
up for a Stripe account you provide them with
information that is essentially the same as would
be provided by the SAQ A and this is enough to
satisfy the card issuers of compliance. If the card
issuers are happy with this then this is another
reason to use Stripe over a PSP as PCI
compliance is a difficult issue for those of us
who do use that method.
Stripe offers significantly more than just a

replacement for a traditional PSP and merchant
account. They have support built in for many

aspects of the payment process including
subscriptions, discounts and coupon codes and
other features to make taking payments simple.
As things currently stand I would make Stripe my
first choice for taking payments simply. I hope
that their success encourages similar new-breed
services as card acceptance is an area that could
certainly do with disruption, and multiple strong
players in that market can only be a good thing.
Complete cart, payment and delivery

solutions
Stripe provides a suite of APIs that includes

some functionality you might previously have
had to code yourself, such as the ability to accept
coupon codes, however some specialist services
go further than this. There are a number of
providers that range from specialist digital
delivery services that can help you sell one off
downloads like ebooks, through to solutions that

offer a full hosted cart. I can’t cover all of these
here but it is worth investigating what is available
- especially if you are selling one-off downloads
and don’t otherwise need much of an
infrastructure around your accounts and payment
systems.
A solution very popular with those self-

publishing ebooks is Gumroad. Gumroad can
host your files and offers a nice payment form
for your customers to pay for your product and
then download it. To use Gumroad to sell an
ebook you don’t need any infrastructure on your
site as they handle both payment and delivery for
you. Like solutions such as Stripe they operate a
rolling reserve and pay out every other Friday all
earnings to the previous Friday. In the USA they
can pay out to PayPal or your bank account,
outside the USA payments are currently to
PayPal only so you would need to account for
the PayPal fees for receiving these payments.

I don’t have personal experience of FastSpring
however they tend to be mentioned in any online
discussion with other product developers.
FastSpring offers a whole host of payment and
fulfilment functionality and allows you to
outsource a lot of functionality that you would
otherwise have to develop yourself.
This section wouldn’t be complete without a

mention of Shopify. Although you might think
of them as being a hosted cart for people selling
physical products they also provide the cart and
delivery mechanism for a number of sellers of
digital products. Five Simple Steps and A Book
Apart currently use Shopify to sell their books -
including ebooks - and Shopify is the system you
used when you purchased this book. Shopify can
act as the hosted cart and store solution,
processing payments via your existing PSP,
PayPal or Stripe or - with Shopify Payments -
take on the entire payment process too. Again, if

selling one off downloads a service like Shopify
can help you to get to the shipping point more
quickly.
Basic Rules for Taking Payments
When businesses run into problems with their

payment solution it is often because they haven’t
understood that their “easy in” payment solution
- be that PayPal, Stripe or any other solution - is
operating under exactly the same conditions as a
full merchant account and PSP set up has to
operate. Ultimately everyone has to dance to the
tune of Visa and Mastercard! The newer payment
solutions act to protect you to some degree from
the complexities of taking payments but if you
are operating a business that is seen as risky or
have a lot of chargebacks or other complaints
then you can expect your payment provider,
whoever they are, to start to take an interest and
potentially impose terms that you feel are harsh.

The following are best practice rules that seem
common to most providers. Whichever solution
you select, make sure that you do read their
terms and FAQs, as if you cannot take payment,
you are not going to have a profitable project.
Start the process of setting up accounts early, so

you do not have to delay your launch due to
waiting for an account to be authorised. In
particular note that it can take a few weeks to set
up a traditional merchant account and PSP.
When setting up your account with any payment

provider complete all information accurately - in
particular make sure you describe the type of
product you are selling and the transaction values
you expect to put through the system. If you are
doing something seen as risky it is far better that
any restrictions are known to you from the
outset rather than imposed retrospectively.

Ensure that you have accurate policies available
on your site. In particular ensure that your refund
policy is clearly displayed and stated and that
customers know how to contact you.
Make sure that the name that will display in the

customer’s credit card statement relates back in
some way to the purchase they made. If
purchases will be logged under your company
name rather than the product name, detail this
on the receipt that you send. That way if the
customer is searching their email to work out
what a transaction is, your receipt should show
up. You should also ensure that your company
website includes an easy way to get in touch if a
customer or their accountant wants to query the
transaction. Make it easier for them to contact
you rather than call their bank.

Make sure contact information is available right
through the purchase process, on any receipt and
on your website.
If unusual activity is about to happen on your

account, for example you are about to have a
major launch, have a sale about to start or have
just been mentioned somewhere high profile
sending a flood of visitors to your site, let your
payment provider know. If they suddenly see a
lot of transactions on an account that normally
only has one or two a day this may well look
suspicious. You don’t want your most successful
day of sales to turn into your most stressful when
people cannot make purchases.
I would advise that to get started taking

payments use whichever service provider can get
you to launch as simply as possible. However as
your business grows it would be wise to ensure
that your payment processing is abstracted

enough from the rest of your app or store that
you could relatively easily switch provider. This
will enable you to move quickly if a provider
becomes unreliable, imposes terms that you do
not accept, stops offering a service that you rely
on or you discover that you could save money or
gain some other benefit by switching. Knowing
that you can change your payment method
relatively quickly protects your growing business.
Hosting
For SaaS businesses the reliability of your hosting
is vital in order that your product is successful. If
it becomes known that your service is often
unavailable due to unplanned downtime, this will
quite naturally be seen negatively by your existing
and potential customers. A reliable marketing
and support site is important even for
downloadable products. Your marketing site is
likely to be the first experience a potential

customer has of your product, and a poorly
performing site might make them feel the
product is equally problematic. In addition, we
bootstrappers rely on word of mouth to some
extent to spread the word about our products.
Poor quality hosting may mean that your
marketing site becomes unresponsive under the
load of visitors pouring in after a tweet from a
popular account. With only one chance to grab
the attention of potential customers before they
scroll onto the next thing, you need to be sure
your site performs well.
Not so long ago your choice for hosting a site

would have been expensive dedicated servers or
poor performing shared hosting that offered you
little control over the environment your site ran
in. These days there are various options that sit
in the middle ground between these things or
offer the advantage of being able to add or to
scale back capacity when needed.

Hosting is something of a race to the bottom in
terms of pricing. If I could give you one piece of
advice it is to ignore price when making your
decision on which hosting to use - even just for a
marketing site. As the founder of a product that
customers host themselves I am well aware of
just how poorly many of the cheaper solutions
perform. It costs money to provision decent
servers, to keep them secure and up to date, and
to provide proper technical 24/7 support. This is
not somewhere to cut corners.
Shared hosting
Even if all you are hosting is a marketing site for

a simple product I would avoid the majority of
shared hosting due to the simple fact that with
shared hosting you quite literally share resources
of one physical server. With regular shared
hosting there is no proper separation of
resources and so one busy site can soak up the

resources making all sites on that server perform
badly. There are some true business class shared
hosting options available however these are in a
different league to the cheap and cheerful
packages offered by many well known hosting
companies and come at a premium price.
With shared hosting your environment, including

versions of languages such as PHP are decided
by the host. If the host is running an ancient and
insecure version of PHP and won’t upgrade you
are stuck with it. You won’t be able to install
caching such as Varnish or any specific modules
required by an application you want to run.
Virtual Private Servers
My preference for most sites that I host is to take

out a Virtual Private Server (VPS) package. With
a VPS you do share one physical server with
other accounts however each virtual machine

should have a set of resources assigned to it that
cannot be soaked up by another machine
running on the same hardware. The benefit to
using a VPS is that you usually can have full
control over the software that runs on the server
- it will in most regards act just like a dedicated
server. This means that you can install whatever
you need to install and keep things up to date.
Unless you have systems administration skills, or
employ someone who does you will want to take
out a Managed VPS package where the hosting
company will ensure your server is kept secure
and up to date and will install the things you
need on it.
Check with the hosting company what the

situation is if you need to upgrade your server to
have more resources - disk space, memory and
so on. We host with Memset in the UK and they
are able to fulfil such requests with the only
downtime being a reboot of the server. This

means that we can take out servers with a low
configuration and increase their resources as we
need to.
Dedicated Servers
A dedicated server means that you have a

physical piece of hardware in a data centre
somewhere. It is fairly unusual these days for
companies to have dedicated servers right from
the start and would be unnecessary for most side
projects.
Cloud Hosting
There is no mystery to hosting in the cloud - it all

ultimately comes down to data centres and
servers. What cloud hosting tends to offer is the
ability to scale up and down resources
dynamically as required. This is unlikely to be
necessary for your marketing site but might be

very useful for your video encoding startup
where you need to have capacity to process video
at peak times but don’t want to have servers sat
around idle when usage is low.
Specialist hosting services
Depending on the type of service or site you

need to develop it is worth checking out some of
the additional specialist hosting services available.
For example you might want to store static assets
on a Content Delivery Network (CDN) such as
Amazon Cloud Front. If you have a lot of data to
store and backup then something like Memstore
might save you money.
How to choose hosting
Recommendations and searching for mentions of

hosting companies is really the best way to locate
a good host. I’ve generally avoided the huge

players and chosen hosts who have good,
technical support; are large enough to have
resilience but small enough for me to contact
their Managing Director or CEO if I need to!
Transparency is an important feature. I have
hosted with companies in the past, and where
there has been downtime they have attempted to
cover it up. I much prefer a company who are
willing to be honest about any issues, explain
what happened and also how they intend to
avoid the same problem happening again. If a
host you are assessing has a status page, take a
look and see how they report problems, see if
they are active in responding to customers on
Twitter, as hosts tend to be very similar until
things go wrong. You want to know that when
things go wrong - as they sometimes will - the
host is responsive and cares about the issue.

Security and Backing up data
You have a responsibility to keep the data about

your users safe. Even if you are storing very
limited data, and it is no more personal than
email address and names, if that data is somehow
compromised you will lose trust with customers.
Make sure that you are aware of any laws in the
country that your business is registered in that
relate to you storing data about customers or
prospective customers. This is especially
important if any of that data could be sensitive if
in the wrong hands. In the UK businesses need
to comply with the Data Protection Act and
should check to see if their use of data requires
that they register as a Data Controller under the
Act.
If your product means that you need to store

sensitive data then you should ensure you have
or can hire the skills to properly protect it, for

most people however following basic good
practices when developing any systems should be
enough to keep data safe. The Open Web
Application Security Project (OWASP) provide a
number of cheat sheets on security related topics
and are a good first port of call to check that you
are following current good practice. Each cheat
sheet provides information about a common
security issue such as resetting forgotten
passwords, and the sheets were created by
multiple security experts in order to best reflect
good practice.
When considering hosting and security you

should also be taking into consideration backup
of your important data. Your host may well offer
a backup and restore service however as this is
within the host’s network you should also ensure
you have a backup of that data elsewhere in
order that you have access to that data outside of
your host’s network, just in case something

happens to that host. Backups should be
automated and checked regularly. Downloading
the MySQL database “when you remember to”
does not count as an acceptable backup solution!
A good exercise is to think through how quickly

you could be up and running on a different
hosting service if something happened to your
current host. Unless you run a service that is
critical to the functioning of your customers’
businesses you could probably withstand a few
hours of downtime - but days could prove to be
disastrous.
Monitoring and Alerts
You need to make sure that you are aware if your

site or application is unavailable, this is where
monitoring comes in. Your chosen host may well
have their own service - however if that runs
from within your hosts network it is going to be

of limited use during a network outage. I would
suggest that you monitor your key servers using a
service that runs outside of your network. There
are a number of SaaS monitoring applications
that you can subscribe to, they then monitor
your server and check that it is responding. A
popular choice is Pingdom who monitor your
site, can alert you in a range of ways if the site
becomes unresponsive and also provide tools to
help you diagnose why you have fallen off the
Internet.
In addition to tools that run from outside your

network to monitor the availability of your site
on the Inernet, you should also be monitoring
the health of your site and application and the
servers it is running on. There are open source
solutions that you can configure to do this,
however if you are limited for time and not
already an expert in Nagios or similar you may
also want to rely on a third party for this. These

applications will require some setup on the server
but are typically straightforward. I like Scout,
which is a lightweight and easy to deploy
application, and big players in the monitoring
market include New Relic and Server Density.
Check these out and see which offers you the
reports and ease of installation that you need.
In particular for SaaS applications where

ultimately success will mean scaling your
infrastructure, being able to see what resources
are being used and plan accordingly is vital to
avoid downtime due to high levels of use or
spending money on capacity that you do not yet
need. If you are running your own dedicated or
virtualised servers I would suggest investing in
some form of server and application monitoring.

Legal Matters
Any sort of legal matter features way down the
list of things I want to have to deal with. Lawyers
and solicitors are expensive and have a knack of
finding new work to do when you approach
them for something simple. However, it is likely
that you will need at least a couple of documents
drafted by a lawyer for your new product, if it is
anything more complex than an e-book
download.
For downloadable software products, you will

want to have a license agreement that explains to
the customer what they are allowed to do with
your software. For example with Perch,
customers are buying a license for one
nominated site running Perch, we also allow
them to nominate a development and staging
domain for that one nominated live site. Just
because it would be technically possible to add a

live domain into each slot per license thus only
needing to buy a third of the licenses needed for
all of the sites, it is against the terms of the
license. We would be within our rights to
withdraw the license from that customer.
Thankfully we have never had to do that, in part
because if we spot that is happening we can
contact the customer and let them know they are
acting against the terms of the license and that
they need to buy additional licenses for the sites.
For SaaS applications you will need to have some

details of what you do with customer data, what
will happen if the service is unavailable, whether
customers are able to export their data and so on.
You may want to have a formal Service Level
Agreement (SLA) and will probably need to have
if your ideal customer is a larger company who
will expect this information.

These agreements protect you and your
intellectual property, but also protect the
customer and make sure they are clear before
purchasing what they are buying or signing up
for. You may also need to protect your company
by way of protecting trademarks, and again this is
something a lawyer would be able to advise you
on.
I am not a Lawyer
My advice is to find a lawyer or solicitor who is

used to dealing with small companies and digital
products. We have recently taken on a new legal
advisor who is well versed in the IT sector and
has other similar clients to us, this makes
explaining what we do far easier. They also offer
a retainer agreement, meaning that we pay them
monthly and can use an allotted number of hours
as we see fit - whether that is for advice or
drafting documents. It is a nice way to spread out

the cost of having license agreements revisited
and also to have someone available who knows
our business if anything were to happen that
required a rapid legal response. We found our
advisor by asking for recommendations on
Twitter - personal recommendations are very
valuable once you are outside of an area in which
you have expertise.
There are websites in most jurisdictions that

contain template agreements and terms that you
can download and customise for a small fee. If
your product is very simple and low cost you
may well find that something off the shelf meets
your needs. Personally however, I like the
security of having a professional in these matters
ensure that we are not accidentally creating
problems for our company by getting things
wrong.

Stats and tracking
In the year 2000 I worked at a “dot com”
company. Back then the only information that
we could gather from visitors to our website was
from the Apache logs. One of my weekly tasks
was to process and analyse these log files to see
what information we could glean about traffic,
mostly so that it could be used to encourage
advertisers. In one meeting the CEO asked me,
“so … how many of these visitors are women?”
I explained that Apache log files could not tell us
that information, and my team had a good laugh
about the conversation later that day. That
question was ridiculous at the time, however
today we have unparalleled ability to track our
visitors and customers and quite often can know
a lot of personally identifiable information about
customers and their usage of our apps. This
section is about using the information available

to you to improve your application and
conversion rates.
Gathering information about the visitors to your

site should start as soon as you post your landing
page. However I would advise against spending
too much time obsessing over this information
as a lot of the information available about
metrics and analytics is written for companies at
a later stage. Initially you need to know a couple
of things.
• Where are people coming from?

• How many of these people sign up/try a
demo/buy a copy?
Worrying about the number of “hits” or even

visitors, as we did back in the dot com days when
all we had was Apache logs, isn’t particularly
useful to you. A small number of visitors with a
high rate of those signing up is more valuable to

you than a large number of people looking at
your homepage and leaving.
The percentage of visitors who come to your site

and then sign up or buy something is described
as your conversion rate. A basic level of tracking
needs to enable you to monitor that conversion
rate, see which traffic sources convert the best,
and to see if any changes you make to your site
or landing page make a difference to that rate. In
particular if you are doing any kind of paid
acquisition, if you do not know whether
customers from that traffic source convert, you
are just throwing money away.
You can get this information using Google

Analytics, or by using a service such as MixPanel
and implementing simple funnels so that you can
answer the basic question, “Which traffic source
gives me the highest number of conversions?”

As you start to build a customer base you may
want to track this funnel through a few stages.
For example:
User arrives at the site -> User signs up for a trial

-> User subscribes to a paid plan
User arrives at the site -> User watches your

intro video -> User signs up for a trial -> User
subscribes to a paid plan
By tracking this funnel over time you may realise

that visitors who watch your video before signing
up for a trial are 10% more likely to convert to a
paid plan after their trial. Perhaps the video
better qualifies the customer, they know what
they are signing up to try. Or perhaps the
information given in the video helps them to
understand your product so they get better use of
the trial and are more likely to move on to a paid
plan. Further testing, trying to get that video in

front of new users will hopefully help you to
know which. However this is an example of the
sort of analysis you should be doing. Just looking
at a climbing graph of visitor numbers gives you
nothing actionable.
Good data should at the very least answer a

question, for example “is it worth paying for
traffic from this source?” and ideally will give
you something to test and act upon. For example
showing you that if a new signup performs
certain tasks during their demo they are more
likely to convert to a paid plan. Once you have
this information you can act on it, then continue
the analysis to see if it does make a difference to
conversions.
Don’t get too caught up in this at first. Make sure

that you can quantify the results of any paid
acquisition, and that you have at the least Google
Analytics on your landing page or site so that you

are starting to collect data from the beginning.
You will soon find that you have questions about
your visitors that you would like to answer and
you can then start to use your data to try and
answer these questions. This approach will save
you spending time messing about with software
before you really have an idea of what you might
like to know.
Take Action: Infrastructure

In this section we have covered some of the
practicalities of selling your product. Some of
these things you should start to think about early
in the development process of your application
in order that setting up your payment method, or
getting terms written by a lawyer do not slow
down your launch.
1. Decide how you want to take payment for

your product.

2. Sign up for accounts at your chosen
payment provider(s) making sure to give
information as accurately as you can.
3. Make sure that you read the terms under
which your provider offers their service
and that you know what you need to do
and to have on your site to comply with
those terms.
4. If you need to find hosting, start to
research your options. Ask around for
recommendations.
5. List any terms, SLAs or license
agreements that you believe your product
should have.
6. If required find a solicitor or lawyer who
understands your business to write these
documents for you.
7. Sign up for a Google Analytics account or
other analytics service so you are ready to
add this to any landing page or site from
the start.

Chapter 6: Identity
and Brand
I am not a designer, and neither is my co-
founder. However we have always cared deeply
about the identity of our product and the
experience of customers using it and the
associated materials. In this chapter I share some
of the things we have learned about identity and
brand, and talk to some founders who are more
qualified than I to give advice in this area.
Visual Identity
My product has a strong visual identity, using
illustrated characters and an informal ‘non-
technical’ feel about the marketing materials.
This was a very deliberate choice, we wanted
Perch to be different and to look different when

compared to the very technical identity of other
products. We want using Perch to be fun, and
for the materials to reflect that.
If you are entering a crowded market then a

strong visual identity can help set you apart in
the minds of people who are researching
solutions. However your design needs to be
optimised with converting visitors into
customers. Having a lot of people like your
marketing site, and adding it to inspirational
design websites is all very nice for the ego, but if
the visitors don’t turn into customers it won’t
help your business.
Interview with Brian Casel
As a developer, running a product company with

another developer, we know design is one of our
weak points. We are lucky to be able to
outsource a lot of our design work to specialist

freelancers, and enjoy having their input into our
product. However, in the early days we did
launch with a website we designed ourselves and
I think it is perfectly possible for non-designers
to create a simple site selling their own product,
to get things off the ground.
Fellow bootstrapper Brian Casel recently

launched his book Design for Conversions. It is
a fantastic how to guide to help designers and
non-designers understand the role design plays in
converting people into customers. I asked him a
few questions.
Q. What are the dangers for designers

to be aware of when working on their
own product websites?
You know everything there is to know

about your product, and all that went
into building it. But the truth is your

customers don’t care about all of that
stuff. They only care about a few key
components — the things that truly
resonate with them, solve a particular
pain, etc. When designing a site for your
own product, you have to break away
from the way you see your product, and
focus on how your customers view your
product. Highlight the parts that
resonate most with customers.
Q. What advice could you give to

developers who feel that design is a
weak point for them but perhaps
don’t have the funds to hire
a designer for the marketing site or
landing page right now?
Sometimes learning just a few simple

design principles can go a long way
towards turning a weak design into one

that works well, or at least good enough
to build early traction before bringing on
a more experienced designer. For
example, learning about visual hierarchy
can help a lot when creating a landing
page.
When you understand why things work

in a design, you can better evaluate your
own design and improve it.
Q. Do you have a top tip or two for

creating landing pages that
encourage sign-ups for pre-launch
apps?
It’s important to give a lot of

information, and give some kind of
incentive for signing up. A simple, one-
liner plus an email opt-in, is too vague in
my opinion. Tell people all about your

product (even if it isn’t built yet).
Connect with their pain point and tell
them why they should care about what
you’re building. If you can also offer
some form of relevant education (a free
email course, ebook, etc.) as both an
incentive to signup and a means for
keeping in touch between now and
launch-day, that’s even better.
Q. What are the biggest mistakes you

see people making on their product
home pages?
Too many things competing for the

customer’s attention. It’s important to
stay focused on a single pain/problem
and tell how your product solves that.
On that same note- too many sites try to

tell the whole story all on the homepage,

“above the fold”. This isn’t possible.
It’s much more effective to unroll your
message piece by piece, compelling your
visitor to scroll down and dig deeper to
get the answers they’re looking for.
Identity Through Voice

In addition to visual design, you can develop a
strong identity for your product through your
copy on the sales page, in emails and within the
product itself. To do this you need to identify the
tone that you want to take with your customers
and try and maintain a similar tone every time
you speak to them - whether that is through an
alert in the application, an email to help them get
started, or even a payment notification.
A company who really stands out in terms of

doing this, and who have been kind enough to
share what they know with other companies, is

MailChimp. When you use MailChimp you will
encounter the illustrated character of Freddie,
however the strength of the brand is very much
about how they use that character to
communicate as you use the application. The
“voice and tone” used has been formalised and
published as a website where you can read how
to write Freddie’s jokes, write for the getting
started guide and even post to Twitter. While the
voice used for MailChimp isn’t for everyone, and
some products require a far more serious
approach, the different sections of this Voice and
Tone guide could be used as a starting point for
your own guide.
Even if it will just be you writing all of the copy

initially, a guide helps you to remain consistent. It
will then make it far easier to bring in someone
to help with writing content in the future -
ensuring that all of your communications
demonstrate your brand and values.

Writing Marketing Copy
As with the design of your marketing site, the
content of the site or initial landing page needs to
perform a job. It needs to encourage visitors to
sign up, or to at least dig deeper and find out
more about your product or service. Writing well
in the context of your marketing site means
writing for conversions.
This is harder than it sounds. I’m an

accomplished writer, and many times published
author, yet writing marketing copy on my own
sites is the only time I experience true writer’s
block. What I find helps is to truly put myself
into the position of my ideal customer. What
problems do they have? What do they care about
in my product? I generally find that the things
customers care about most deeply are not those
that I think are the best or most exciting features
of our product.

I want to tell people about the technical
implementation, our approach to structured
content and the other features that I believe
make Perch stand out above our competition as
a technical solution. Many of our customers
really don’t care about that. They want to know if
Perch can help them build sites faster, whether
the support is good, and how they sell the
solution to their clients over WordPress. My
experience is that those things you believe are
key features, may not be your main selling points.
Sell the main selling points, those that in testing
convert well - people will discover the other great
things about your product as they use it.
The nice thing about copy is that it is easy to

start to do simple testing of what works well, and
without needing to change parts of your
infrastructure in order to test whether one thing
works better than another. If you are taking your
first steps into A/B Testing then copy is a great

place to start. I asked my next interviewee about
how to write great marketing copy and about
how to decide when you have enough traffic to
perform useful tests on copy.
Interview with Joanna Wiebe
Joanna Wiebe is one of the founders of Copy

Hackers, a site dedicated to helping startups learn
to write copy. There is a wealth of information
on the site and Joanna generously shared some
insights with me in an interview for this book.
Q. Could you give me a couple of

examples of “quick wins” - simple
things that bootstrappers can do to
improve the copy on their
homepage or landing page?
If I didn’t lead with ‘test it’, you’d be

allowed to toilet paper my house. By law.

So let me start by saying do your best to
split-test changes rather than simply
making them. Of course, I’m no fool and
neither are you, so we both know that
you can’t actually test EVERYTHING.
You have to make some guesses
sometimes. Just be sure to monitor the
changes you make without testing -
because even the most seemingly
innocuous tweaks, like increasing the size
of your security icon, can impact
audiences in unexpected ways.
But, okay, quick ‘wins’! Here you go:
• Let copy lead design. Don't try to

squeeze copy into inflexible
templates.
• Have one goal per page. Just one.
You may have other minor calls
to action that people can do, but

focus each page on a single goal,
and your visitors will be more
likely to know what to do on a
page... and do it.
• Make all your fonts bigger. If
your page is as easy to read as a
children's book, you'll cut down
on friction (which is one of
conversion's many enemies).
• Center and bold your headline
just below the global nav. Don't
hide your headline in a rotating
banner, don't push it below a
huge image, and don't squish it
off to the side of an image. Your
home page headline is everything.
Let it shine.
• Communicate what's unique and
highly desirable about your
solution in your home page
headline and subhead. Forget

headline formulas. Your value
proposition - and why it matters
for visitors - is the first thing new
visitors need to see.
• For landing pages, keep "message
match" top of mind when writing
your headline. The call to action
and/or key message your visitor
saw before arriving on your
landing page should be reflected
in the headline and/or subhead
on the landing page.
• When writing copy, don't worry
about SEO. Google continues to
reward natural language; you can't
trick Google, so don't bother
trying! Just write naturally.
• Put extra effort into the small
things, like calls to action and
your navigation. You'll quickly

find that they're among the most
important points on your site.
• Go where the eye goes: to images.
Get more eyes on your most
important messages by centering
them on the page and putting
them near or on your images.
• Never underestimate the power
of an arrow and a snippet of
instructional text. For example, if
you want someone to watch your
video, use an arrow and a
handwritten line of copy that goes
something like, "Click to watch
how we can save you 3 hours
each week".
• Replace "we" with "you".
Nobody came to your site to
learn about you; they came to find
a better version of themselves.
Show them that version by talking

about them - not about you. This
is done quite practically by going
through your copy and rewriting
sentences that lead with "At XYZ
Company", "We're here to", "We
want you to", etc. so that they
instead lead with "You". You is a
powerful word for self-involved
people (which, with rare Mother
Teresa-type exceptions, we all
ultimately are).
• Show and tell. Some people say
you should only show and never
tell what you do, but I've seen -
time and again - that when you
imply you lose people. Implying
requires visitors to think, and
that's a no-no online. So show
people how wonderfully your
solution solves their problems...
and then explicitly tell them.

Q. How much traffic does a site really
need to make A/B Testing headlines
and buttons feasible?
When testing, it’s often best to consider

the amount of traffic to the page in
question rather than to a site. Sites with
huge blog traffic may have relatively low
ecommerce traffic or squeeze page
traffic. You want great traffic to the page
you’re testing.
We recommend that you have at least 50

conversions per recipe (including the
control) before you call a winner on a
test; a lot of testing tools will call winners
at - for example - 11 conversions on one
variation and 7 on the other, which is
just not enough to be anywhere near
conclusive. We also recommend that you
close a test no later than 4 weeks after

launching it, and ideally in less time than
that.
So with that in mind, think of your

current conversion rate and use that to
calculate the minimum amount of traffic
you’ll need to have to your page during
the 1-month period it’s running.
Let’s say you’ve got a 2.2% conversion

rate on the page you’re testing. A little
basic math shows us you’d need about
2300 visitors to each variation - or at
least 4600 visitors a month - to run a
two-way test. Of course, if you’re testing
something that’s got relatively low
impact on conversion, like a new
subhead well below the fold, you’ll need
much more traffic than that to move the
needle. For testing headlines and primary
calls to action, that per-variation

calculation - (50 x 100) / [conversion
rate] - should be pretty close.
Q. Do you think that most people are

capable of writing their own copy?
When is it time to get a professional
in?
Definitely! I think most business owners

and product owners are the best people
to write their own copy IF they get a
little basic training from the right folks
first. I’ve seen too many startup founders
fixate on what their high school English
teachers told them and buy too easily
into trying to mimic Apple’s marketing /
messaging; you don’t want to write copy
your English teacher would like because
copy is not about grammar and well-
formed paragraphs, and you’re not
Apple, so why write like they do?

Basic tips - like avoiding walls of text,
leading with your value prop when
you’re a new biz, using natural language,
cutting ‘clever’ copy, selling the visitor a
better version of themselves (not your
product) and making yourself
uncomfortable - can go a long way when
writing copy.
That said, some people are simply a)

crippled by fear of writing or b) too in
their heads to loosen up and get the job
done right for visitors. If that’s the case -
or if you’ve tried everything but your
conversion rate is stuck in a pit - call in a
pro. But not any “pro”. Most business
owners would do best to seek out what
we call a “conversion copywriter”, which
is essentially a web and email writer who
understands traffic but is most focused
on writing copy that sells. (These are not

direct response copywriters, who also sell
via long-form sales pages; rather, these
are copywriters who can move units in
palatable 2.0 environments.) Yes,
conversion copywriters are more
expensive - but if you’re serious about
growing your business, a great copywriter
is a critical investment. Expect to pay
upwards of $100 per hour. To get the
most bang for your buck, focus your
conversion copywriter on your home
page and your most critical pages for
conversion, such as pages with sign-up /
opt-in forms and your cart. When those
pages bring in more biz for you, reinvest
it in more and even better copy: bring
that conversion copywriter back to
optimize your emails, thank-you pages,
etc.

TIPS: Check the portfolio or case studies
of a copywriter before hiring; you should
see A/B test results in their work, and
they should be able to talk about
conversion and demand-gen
philosophies. When you hire a proven
copywriter, get out of their way. Never
assess their copy based on whether you
“like it” or not because it’s not about
you; it’s about your prospect.
Take Action: Identity and

Brand
Developing your identity and brand is an
ongoing process, however given that at the very
least you will need to have a simple site or
landing page to announce and then to sell your
product, you should start to lay the foundations
now.

1. With your ideal customer in mind, think
about how your product should present
itself. Is an informal or formal tone
appropriate?
2. If you are using external help to design
your identity and site make sure they
understand the tone that is appropriate
for your customers. Remember that a
beautiful site is not necessarily one that
converts well.
3. Begin to put together a document
detailing the voice and tone you will use,
add to this as you start to write copy for
your communications and
documentation.
4. When talking to potential customers and
those interested in your product, take
note of the things they want your product
to solve. Those are the problems people
will be looking for answers to when
reading your marketing copy. Make sure

they are reflected in your headline
features.

Chapter 7: Setting up
for Support
You are likely to have to offer some support for
your product. It may be as simple as helping
people with their purchase or dealing with
refunds, right through to real technical support.
Having a way for customers to contact you and
for that support to be helpful and rapid will be
important to your customers.
In my own experience good support is seen as a

valuable feature to customers, in particular where
those customers are using their product to run
their business or to provide services to their
clients and customers. If they need help, it may
be because they are reacting to something their
customer is asking them - being stuck in the
middle is stressful so if you can be responsive

and help them out they will be grateful and feel
positively about your product or service. This is
often even the case if the issue was a genuine
problem with your product, rapid help seems to
generally outweigh the initial issue.
Providing support can also be valuable to you

and the development of your product. I do feel
that it is important for the people developing a
product to also support it, at least some of the
time. Through helping your customers you will
learn first hand where the pain points are in the
product, discover ways to improve your offering
and learn about the features customers would
really like to see.
Support as Marketing
“If you make customers unhappy in the
physical world, they might each tell 6
friends. If you make customers unhappy

on the Internet, they can each tell 6,000
friends.” — Jeff Bezos
Last year I bought my daughter a FitBit. She had

it for about two weeks, took it off and left it on a
windowsill at school during a dance class, when
she went back it had gone. She contacted FitBit
after visiting their support site and following
their instructions to use the connection between
the device and her phone to see if it was in range.
To her (and my) amazement they offered to
replace her device free of charge. She had lost
the FitBit, it hadn’t malfunctioned or broken, yet
they mailed her out a brand new one a few days
later.
I have told this story many times, I’ve mentioned

it on Twitter and Facebook, I’ve told friends in
person when asked my opinion of which fitness
tracker I like. I do sometimes mention the
features of the FitBit - however the story I tell is

the one about how the company sent a new
FitBit to my daughter when they had absolutely
no obligation to help out a careless teenager!
I know that several people have bought a FitBit

device on my recommendation, and this is an
example of how excellent support, support that
goes over and above what we have to do, can be
a great marketing tool. People talk about good
support, and they talk about bad support. In the
case of poor support they often use the internet
to try and get the company they have a grievance
against to take notice, as they understand how
visible something like Twitter can be.
A new product is likely to have some issues that

need ironing out. No matter how carefully you
have tested everything, real users will find ways
to break things that you could never have
imagined. In particular if your product, like mine,
needs to run in the customer’s own environment

you are likely to find issues due to issues with
their hosting, computer or device that you hadn’t
accounted for. These first few customers are
incredibly important to you, you want them to
have a great experience and to talk about it - help
you spread the word. Being ready to jump in and
go over and above the call of duty here is really
important and in this chapter we will talk about
how to get set up to offer noteworthy support
from the day of launch.
Support as Product Research

Before going on to talk about the tools available
to help you to offer support I want to mention
another, often overlooked, benefit that you can
get from doing support. By helping people you
get a very clear idea of the places in which they
are having problems, or the limitations that they
are running up against. It is for this reason I
would encourage you to do your own support

initially rather than seeing it as something you
could outsource.
Some issues are just a bug or problem that needs

fixing, these should be dealt with as quickly as
possible. In a SaaS application you should be able
to push a fix quickly. If the product is a
downloadable it can be more difficult to just
quickly send out a fix, but perhaps you can give
that customer a patch to keep them moving for
now while you test a new release. For
downloadable software it is really important that
you keep it in a state where you can deploy a
patched version easily. In your version control
you should be able to work on a feature branch
leaving the master branch in a deployable state if
some critical bug comes up and you need to react
quickly.
If the bug isn’t a showstopper for anyone it may

not need fixing with high priority - sometimes

customers will just pop into support to note
something they have been able to work around
but realise isn’t exactly as expected. You don’t
need to feel like you have to leap on every issue
as if it is an emergency, but remember to thank
the customer for bringing it to your attention and
let them know when it has been fixed in a
production or downloadable version.
Sometimes issues with your product are not

directly reported by customers, you will just note
that a large number of people seem to run into
difficulties with the same thing. There will always
be people who struggle with even the most
carefully documented and simple to use things,
however if a lot of people are getting stuck in the
same places that does indicate either an issue
with the software or a lack of documentation.
Use this to improve and remember that for every
person who comes into support for help there
will be a number who do not, and perhaps give

up on using your product as they find it too
confusing. Be happy about the puzzled people
who speak to you - they are helping you to
improve your product!
You can also use support to find out which

features are a priority to customers. People will
often come into support asking how to do a
thing that isn’t possible right now, or is only
possible by jumping through a lot of hoops. This
is a great chance for you to gather use case
information for new features.
Support can be a goldmine of information about

how to improve your product for everyone. To
make the most of it, and to help you manage
support as part of your busy workload, you need
to get set up with the right tools and the rest of
this chapter will talk about how to choose tools
for support and set up systems that will help you
help your customers.

Tools for Support
If there is more than one of you supporting your
product from launch then I would suggest that
using a shared mailbox to provide support is a
poor decision. While your customers will enjoy
being able to simply email you, emails in a shared
mailbox are very difficult to manage. If one
person reads the mail but thinks the other would
be better placed to deal with it, it may disappear
in the list and never be answered. Or you will
both reply to the same email at the same time,
wasting effort and providing a confusing
experience to the customer. Even if support will
be offered just by one person at the start, there
are some great benefits to be had by
implementing some sort of help desk software.

Ticket management
The obvious use of help desk software is to

manage tickets and ensure that every support
request that comes in is dealt with by the best
person and answered efficiently. Good help desk
software should allow you to claim a ticket, so
that two people don’t go to the trouble of
answering the same thing, and be able to keep
track of that ticket until it is closed.
You should be able to view all the outstanding

tickets so that if a member of the team is away
you can view tickets they were involved with and
take on the conversation. This is a benefit over
using email where if people reply from their own
account the conversation ends up in a personal
mailbox and might be left hanging for a few days
while that team member is unavailable.

Support statistics
A less obvious benefit of using help desk

software is that many products give you statistics.
You can see which were your busiest support
days and see whether you did something, perhaps
added a feature to the product, that caused more
people to need support. You can plan for future
employment needs by seeing how support is
growing in comparison to your customer
base.You will also be able to track information
such as how quickly tickets are responded to and
resolved.
Canned responses
No matter how great your documentation and

how simple to use your product may be, some
people will not read and so you will spend some
time saying the same thing over and over again.
Most helpdesk software includes the ability to

add “canned responses” with a couple of clicks.
These save you time, by not needing to look up
the same link in the documentation or give the
same advice repeatedly, but also ensure a
consistent response to customers.
Being ready for scale
Implementing a system for support mean that

you will be ready to add another person in this
key area if your product starts to see a lot of new
customers. If your product is taking off, having a
system in place for support means you can
quickly add new support people, rather than
needing to research and implement a new system
when you have so many other tasks to do.

Public Forums vs. Ticketed
Support
Many help desk products come with public
forum software included, or the help desk itself
may be completely public forum based as is the
case with Tender. As a product owner you may
be tempted to think that having a forum on your
site will enable your users to help each other.
However for this to happen you need to have a
very large amount of users, just to ensure that
enough people are looking at your forum for
some of them to be experienced enough to help.
At Perch we only very rarely find forum posters

helping each other out. This makes sense
however if you look at the statistics for support.
With only around 25% of our customers ever
coming into the forums to ask for help, those
that do tend to be the newer customers and

those who need help with the more technical
aspects. Many of our more experienced
customers have not been near our support
system in months or years. So the customers
who would be best placed to help others, tend
not to be visiting the forums, beginner users who
are in the forums are not yet in a position to help
out.
You will get the occasional person who really

enjoys helping others who will post, however I
don’t think this is something you can count on.
Where public support does seem to work is
where it happens in a place where there is some
benefit to getting involved - for example on
Stack Exchange sites such as the one for
ExpressionEngine. On Stack Exchange users can
gain reputation points for answering questions
well. It would be interesting to see if this kind of
system could work on a product support site,
perhaps with incentives for top users.

We used Tender for Perch initially but moved
away from it due to the public forum nature of
the system. Where customers did help each other
out it was hard for the original poster to know
whether the answer they had received was from
one of us - an official answer - or just from
another customer who might be well meaning
but incorrect. There were occasions where a
customer became annoyed thinking that the were
being given bad advice by the Perch team. In
addition, supporting Perch often involves us
finding out a lot of information about the
customer’s installation and website, it may be
they are not happy for this to be posted publicly
so a private support system alongside a public
forum was a better way forward for us.
Social Media Support

Some technical support solutions do integrate
well with social media such as Twitter and

Facebook, however with a small team you can
simply keep an eye on these accounts and
respond when you see someone tweet or post a
message. How helpful you can be on Twitter
really depends on the type of product that you
have.
For us, support often involves writing code, or

viewing the customer’s code. This doesn’t work
well on Twitter so quite often when someone
asks a question we need to direct them to
support, however it is a chance to give them
some advice so that we can help them quickly -
for example saying that we will need to see their
template code or Diagnostic Report. Sometimes
the question can be answered be tweeting a link
to something in our documentation, or just
explain that yes Perch can do that or no, that
isn’t currently a feature.

Twitter and Facebook are such visible mediums,
to take advantage of the marketing effect of good
support you want to ensure that you are
responsive there and communicating with
customers even if ultimately they do need to take
the communication to another medium so that
you can help them properly. When it is your
product and you are also running the social
media accounts you have an advantage over
larger companies who outsource this activity, or
pass it to support staff. You can talk to your
customers directly, you will learn more about
them and they will appreciate having the ear of
someone who can directly solve their problem.
Pre-sales and purchase

support
An important part of support is the support you
offer before customers make a purchase, or even

before they sign up to try out a demo or free trial
period. They may have questions about the
product in order to be able to make a decision as
to whether it is right for them, or they may be
having a problem purchasing - perhaps their card
is not being accepted for some reason.
While these pre-sales queries are not yet

customers, and you may see them as a lesser
priority than the people who are already giving
you money, it is important to be responsive to
them. Many potential customers will make a
judgement about your product and the level of
support based on the responses to their pre-sales
queries. After all, if a company cannot get back
to someone who is thinking of giving them
custom, will they be interested in helping after
the purchase?
While we have always placed a strong focus on

technical support for Perch, pre-sales queries

were often falling through the cracks. This was
because we had fallen into the same trap with
these as I recommend you avoid for support. We
were using a shared mailbox for our
hello@grabaperch.com account and as we each
would assume the other would answer a query,
they were often missed. With our help desk
software provider UserScape bringing out their
new product Snappy, a lightweight tool designed
for managing the workflow of email based
support, we decided to try that just for managing
the pre-sales emails. Having those available in a
managed way has made all the difference and I’m
not now embarrassed by people having to email
us twice to ask a simple question before buying
Perch.

Dealing with Difficult
Customers
No matter how fast your support and how
friendly and competent you and any support staff
that you hire are, there will be customers that are
impossible to please. In some cases you can start
to feel as if they bought your product just so that
they could spend their day complaining to you! I
think most people who are launching a product
worry that they might have to deal with people
who are upset or angry due to something their
product has done or has not done, however our
experience is that really difficult customers are
fairly few and far between. Most can be turned
round to being a happy customer with careful
handling! Some of the types of difficult
customers we have encountered are detailed
below, including tips for dealing with these
people.

Customers who expect poor
treatment
Sometimes customers will arrive in support fully

expecting bad treatment, and essentially behave
aggressively from the outset telling us how angry
they are and how stressed they and their clients
are due to something they perceive as being our
problem. In almost all cases, if you can help this
customer out quickly and calmly their attitude
will change. It is not unusual for a customer to
post a really angry ticket, we help them out
quickly and they will then post an apology about
their initial tone!
Take a deep breath and respond to the angry

customer as if they had made their request nicely,
and you can usually diffuse this situation quickly.

Cultural issues
As a digital product it is likely that your

customers will come from all over the world,
they may be using a language they do not speak
well to request support and this can come across
rudely. It is generally fairly easy to see from email
addresses or names that someone is probably not
a native English speaker and you can keep that in
mind if their responses seem somewhat abrupt.
Another element of having an international

business is that different cultures have very
different expectations when it comes to support
and how they will be treated. This can be
particularly true if you are operating under
legislation of your own country which is different
to what is normal in another country. Ensuring
that your terms of business and other policies are
clear and understandable can really help here - or
at least give you something to show to a

customer who believes they are being poorly
treated due to these differences.
Customers who lie
Something we see fairly frequently is the

customer who will not tell us the truth. Without
knowing what they have done, and the
environment our product is running in, it is really
very hard to properly help them. The first thing
we need to know is which version of the
software they are running and the steps they took
to get to the problem. Customers will tell us they
are running a newer version than they are,
because they don’t want to upgrade, or they
neglect to mention that prior to the problem
happening they have been “making some
changes” directly in the database. All this does is
delay them getting help.

If possible build reporting into your product so
that you can see for yourself the state it is in
rather than relying on customer information that
may be confused or completely incorrect. In
Perch we have a Diagnostics Report that shows
us the versions of the core software and any add-
ons and a lot more information that we can use
to help customers.
You do tend to get pretty good at spotting when

a customer is not being entirely truthful, and in
general asking a direct question will cause the
truth to come out. I can only assume that
customers do this is because they think they
won’t get help if we realise that they have caused
their own problem. No-one likes to feel silly or
that they have broken something. Being very
clear that you will help, and are not there to
reprimand them, but you just need to know
exactly what state things are in in order to help

quickly is the best thing you can do to make
people feel safe in telling you the truth!
Customers who are using the wrong

product
My heart sinks when we get a pre-sales query and

it is obvious that this potential customer is not a
great fit for our product, we explain that to them
and they go on to buy a copy anyway. Before
long they are in support and upset because they
do not understand the support materials or the
product isn’t doing something that we have
already told them it doesn’t do. I would have
thought that the product developers telling you
that this product is not the thing you want would
be enough to put people off but strangely
enough it isn’t!
There isn’t a lot that you can do about customers

who are simply using something that is wrong

for them, if you have a refund policy you can
always refund them, but that won’t help with the
people who insist they want to use the product
while complaining about things it doesn’t do!
The best advice is to take a deep breath and treat
them with the same respect as anyone else, in
particular if they are complaining in a public
forum people will see that you are being
reasonable and fair and not take this person’s
complaints as indicating a problem with the
product.
Truly difficult people
The truly unpleasant person is thankfully a very

rare occurrence. If you treat people well and with
respect they will usually respond in the same way.
Understanding that people are often stressed by
the time they make it into support, or are finding
it hard to communicate, and dealing with them
fairly and quickly can go a long way to turning

around most situations. You should not feel
obliged to continue to offer a service to someone
who is continually and without reason unpleasant
to you or a member of your team. Avoid arguing
with a customer who is just being unpleasant,
often the best way to deal with it is simply to
ignore any nastiness and just respond to
legitimate questions within the ranting. Once
they see they are not getting a reaction, they will
often move on.
Take Action: Support

Whether your support materials involve a short
FAQ and email address to contact for help, or a
full help desk system and comprehensive
documentation getting set up to support your
product could well cause a delay to your launch if
you haven’t decided how to manage it in
advance.

1. Keeping your ideal customer in mind,
decide how you will support your
product.
2. If you intend to use a third party help
desk, draw up a shortlist of features that
you can use to assess the different
products on the market.
3. Refer back to the competitors that you
researched earlier. How do they support
their product? Can you find out from
researching on Twitter or by looking at
their public support how their customers
feel about the quality of support they
offer? How will you offer a better service?

Chapter 8: Planning a
Launch
If you simply sit and work at your product until it
is done then launch it, you’ll probably find that
not very many people are interested. You’ll then
have to start creating an audience and marketing
the product. Instead you can be starting to create
that audience and interest in your product while
doing the work on the product itself. Your aim
should be to launch it to people who are really
excited to get their hands on it, who are already
interested and ready to buy.
In this section we’ll take a look at some ways that

you can start to create interest in your product
before you launch, and also how to ensure you
have a way to tell people when the product is
ready and available to them.

Pre-launch Pages
About a month before we launched Perch we
published a simple landing page at the
grabaperch.com domain. It had a short video
explaining how Perch worked, recorded by
Drew, and a form to sign up to be informed
when Perch launched. That signup simply added
the user to a Campaign Monitor list. We didn’t
know a lot about launching a product at the time,
but as it happened we had stumbled upon the
very thing that everyone I have spoken to has
said is the most important thing you can do -
start to gather email addresses for your launch
list.
Your initial landing page does not need to be

much more than a description of the problems
your product seeks to solve and an email sign up.
It doesn’t need to be a full website, just enough
so that people know what the product will do for

them, and be interested enough to want to know
more. The important thing is that you have
somewhere to direct people to when you talk
about your product, and you have a way of
getting their contact details so you can let them
know when the product is available. If you are
running any kind of initial beta you might want
to explain how people can be added to that.
Joanna Wiebe, who I interviewed in an earlier

chapter of this book had some great advice for
readers when it comes to their landing pages. I
asked her what mistakes do you see people
making in terms of the copy on these landing
pages?
“The biggest mistake is almost always the

headline. Some well-intentioned but
inexperienced person has been spreading
rumours that your headline should be as
short as humanly possible - as if

Hemingway is writing it. But Hemingway
wrote news stories and fiction, not copy
… so why would we do as he did? Don’t
write a headline for Hemingway; write it
for your visitor.
A few others:
1. Hiding your personality. Right

now, you're not a product; you're
a person. Help your prospect
connect with you by adding a
1-min video to your page that
tells them who you are and why
you're creating this product. Be
natural in this video. Try not to
do a spooky webcam video - the
camera on your smartphone can
probably shoot a better video
than your webcam can.

2. Too many form fields to sign up.
The difference between asking for
name + email and asking for
email only could be significant;
you'd be amazed at how quickly
people give up on a two-field
form vs a one-field. If you have
no plans to communicate
'personally' with them, why ask
for their name?
3. Friction-y calls to action. If your
button copy is "Submit" or "Sign
Up", it's full of friction. Your
button should usually complete
the line "I want to...". Nobody
wants to submit, and nobody
wants to sign up. Rather, they
may want to be first in line to try
your solution... in which case the
button could be "Be the First to
Try [ProductName]".

Another big mistake is acting like this is a
one-way communication. It doesn’t have
to be! If you’re in early stage
development, you should be trying to
collect data from prospective users - so
use your pre-launch sign-up page to
collect data! When you get people to sign
up, ask them one other question that will
help you with your product. For
example, what are they currently using to
solve the problem you’re trying to solve?
Collecting their thoughts on that
question alone could help you discern
differentiation opportunities, pricing
strategies and levels of awareness, all of
which will help you when the time comes
to launch your product and/or pitch to
investors.
Finally, although this is not about on-

page copy, a huge miss is failing to have

a drip campaign for new leads and failing
to keep in contact with them over the
course of the months you’re building.
Plot out a simple autoresponder
campaign that drips engagement-
boosting emails to them over the course
of the next 3 months or so; every week
or every 10 days, send them surveys,
status updates, musings, challenges, early
feedback - anything to keep your name
top of mind for them. Otherwise, you’ll
have a big ol’ list that won’t open those
critical “We just launched!” emails … in
which case, why did you even bother
collecting their names?”
With a landing page in place you can start to pre-

announce your product. If you already have an
audience of ideal customers on Twitter, via your
blog or perhaps in communities that you are part
of then you have somewhere to start. Don’t

forget to ask these people, who already know
you, to share your landing page and tell others
about the upcoming release. I am always happy
to retweet or mention things that people I follow
are doing - and most other people are the same.
Don’t be too shy to ask people to help you get
the word out.
Interview with Sacha Greif
You can begin marketing as soon as you have

that landing page in place, trying to reach those
outside of your immediate contacts. Sacha Greif
is a designer who has launched several successful
products including Folyo - the service I discussed
early in this book when talking about how to
outsource work and is co-author of the book
Discover Meteor. I asked him some questions on
marketing bootstrapped side projects.

Q. What key things should people
bootstrapping a side project do while
they are pre-launch to start to spread
the word?
If you only do one thing, it should be

building an email list. Now, you might be
thinking that since you’ll never be able to
accumulate thousands or even hundreds
of subscribers before launch, building an
email list isn’t going to be any use. But
think about it: even assuming you only
manage to reach out to 20 people, how
else are you going to get the word out to
those 20 people once your product is
live? Unless you’re planning on sending
20 individually crafted emails, having a
list just makes sense. After all, you only
get a chance to launch once, so you need
every bit of help you can get. It would be
a shame if your launch was a flop just

because you weren’t able to reach your
audience in time. Plus, another benefit is
that asking people to give you their email
is a good way to judge demand for a
product. If you’re able to convince
people to take even 10 seconds out of
their busy day to sign up for a mailing
list, it’s generally a good sign that you’re
doing something right!
Q. When sending emails to a pre-

launch list, how do you ensure that
people find the emails useful enough
to not hit unsubscribe?
Try to make the emails about the reader,

not about you. Put another way, unless
you’re Apple, Louis Vuitton, or Ferrari,
your readers probably have zero interest
in your actual product or brand. What
they’re interested in is what your product

will let them accomplish, or as Kathy
Sierra would say, which superpower it
will give them. So as with any blog post,
try to make sure each email you send
contains useful, actionable advice.
Another nice tip is involving your

audience in the process of building your
product. Ask for feedback, run a poll,
ask questions. This works especially well
for books or courses. You goal shouldn’t
be just to build a one-way email list, but
to build a community around your
product.
Q. Do you have any advice for how to

solicit reviews of your product?
I would avoid focusing too much on big-

name bloggers or large sites unless you
already have a connection there. They all

receive countless “look at this great thing
I built!” emails every day and are
probably going to ignore you. Instead,
try to find bloggers who already write
about your domain, even if their
audience is small. Precisely because their
audience is small, these bloggers
probably don’t receive offers to review
products every day, and will actually be
happy to help out.
Q. What does your ideal launch day

look like?
I think our launch for Discover Meteor

is as good as it gets: we had about 2000
emails on our list, people were
impatiently waiting for the book (to the
point of asking us on Twitter and by
email when it was coming out), and to
top it off the Meteor folks were nice

enough to let us hold a release party in
their offices in San Francisco, to which
over 120 people came! This makes
getting upvoted on Hacker News seem
meaningless in comparison, which was
the whole point: it’s much better to be in
control of your launch than be at the
mercy of upvotes or retweets.
Q. Once a product is starting to bring

in money, is it worth using some of
that on paid advertising? If so which
channels do you think give the most
value when you only have small
amounts to spend?
I’ve actually never paid to advertise a

product yet so I don’t know how
effective it would be. But rather than
look at it from a ROI standpoint, I think
it’s better to look at it as supporting the

blogs or podcasts you appreciate by
sponsoring them. So I would prioritize
advertising with cool people that you
like, rather than buying impersonal
Facebook or Google ads.
Q. It is often easy to get some buzz

around a launch, do you have any tips
for keeping that momentum going?
Just take whatever you did to prepare

your launch (emails, guest posts,
blogging) and keep doing it. Also, use
your product to make new connections
and reach out to new people. Having
something to sell is actually a great way
to build a brand and make yourself stand
for something, which will help people
remember you. And of course, you can
always just come out with another new
product! If people like your second

offering, there are good chances that
they’ll be interested in the first one too.
The Slow Launch

I love the excitement of a launch - setting to live
the payment processing, making the new website
live and sending those first emails to your list.
However if you have been successful in building
up a big list of interested people, letting them all
loose on your new product all at the same time
could be the worst thing you could do.
Interview with Rob Walling
I recently heard Rob Walling talk on the Startups

for the Rest of us podcast about his “slow
launch” approach for his new SaaS product,
Drip. This seemed to run counter to the advice I
have read from many people about planning a

big, publicity generating launch, and I wanted to
explore Rob’s thoughts on this further.
Q. Could you describe your “slow

launch” method as you used it to
onboard customers for Drip?
The idea behind the slow launch is to

bring new customers into your
application in groups to test a few things
that can’t be easily tested through other
means: onboarding and support
scalability, technical scalability, and
problem-solution fit. That sounds like a
list of buzzwords so let me dive deeper
into each one …
Onboarding and Support Scalability
Most people don’t think about how

many hours it’s going to take to help new
users to begin receiving value from your

application. If you’re doing it right, these
days you have some kind of concierge
onboarding service that isn’t infinitely
scalable, but means you’ll convert several
times more trials into paying customers.
For example my app, Drip, is an email

marketing application similar to
MailChimp, but focusing on email mini-
courses and autoresponders. We will
build a 5-day email mini-course for free
if you have some content we can pull
from such as a series of blog posts, an
ebook, or whitepaper. This service, while
not free and completely unscalable,
means we have a large number of trial
users who become customers because
they don’t have to do much work to get
value from the service.

But before you run 50 people through
your onboarding sequence (and then
handle early support for that number of
people) you have no idea how much
manpower it’s going to take to handle
things in a reasonable timeframe. A slow-
launch allows you to get a grip on these
numbers without dropping the ball for
too many people along the way.
Technical Scalability
This is about whether your application

can handle the load that will be placed
on it once you have users. This is easy
enough to test with automated tools, but
there are always quirky uses and edge
cases you won’t be able to unearth with
standard testing tools. We ran into an
issue where everything worked for our
customers until they started to have

100k+ rows in the database, then things
slowed down for them over time. New
users saw no degradation in
performance. This wasn’t something I
would have tested, but we ran into it
with a small group of our earliest slow
launch users and were able to fix it
before the second wave saw any issues.
Problem-Solution Fit
This is just whether you actually solve a

problem that’s worth solving (and thus,
that people will pay for). No matter how
well you’ve communicated your value
proposition thus far, you have no idea if
you’re going to solve someone’s problem
until they start using your application.
And if you let 1000 people in all at once
to a brand new app you’re going to lose
most of them because you haven’t had

time to iterate your app yet and add the
features that really nail the problem
you’re trying to solve.
But the slow launch allows you the

luxury of time - time to hold one-on-one
interviews with early paying customers to
figure out what else they need in your
application to make it a no-brainer. I
found that the more of these “no
brainer” features we implemented, the
more people we retained in our next
round of the slow launch. By the end of
our 3500 person email list, our
conversion rate from trial to paid
showed me we had solved a pain point
for a lot of people.
Q. Were there any surprising results

of your working closely with the first
few customers? For example features

you hadn’t thought of or features you
thought were important but no-one
cared about.
Absolutely; we received dozens of

feature requests in the first few weeks
from about 15 early access customers.
The good part is that I had let in a
mostly homogenous group of customers
- most early stage software/startup
founders. This meant there was a lot of
overlap between the requests, and we
could focus our development efforts on
solving their problems really well. As
soon as I let an e-commerce site owner
and a blogger into early access we started
seeing very different features being
requested, and I knew that we would not
be implementing those (yet), until we had
nailed the value proposition for that first
group.

Q. Did you have any issues in terms
of people wondering why others had
been allowed in already? If so how
did you manage that?
I don’t recall any complaints. I did

receive a couple emails per week with
people asking to be let into the early
access and I had a few basic questions I
would ask them:
1. Do you have an existing website

with at least X unique visitors per
month?
2. What is the URL?
3. Are you willing to pay $49/month
for an email marketing application
that will increase your website
conversion rates?

These are basic qualifying questions - I
needed a “yes” to 1 and 3 to ensure they
were in Drip’s target market. I needed
their URL to confirm for myself that
Drip would be a decent fit for their
needs. If they fit, I almost always let
them in right away.
Q. Do you miss the excitement of a

big launch day?
Not really … if you’ve ever been through

a “big” launch day it’s more stress than
excitement in my opinion. With this slow
launch not only were the latter launch
days less stressful (since we had worked
out so many of the early app growing
pains), but the conversion rates were
higher than they would have been had
we simply sent an email to all 3500
people on day 1.

Take Action: Next Steps to
Launch
As development of your application or the
writing of your course or e-book nears
completion you should be thinking about the
actual launch day of your project.
1. Get a pre-launch landing page live. You

can tweak the content of this over time, if
you are at a very early stage this page can
be very simple - as you get closer to
launch use it to drip more information
about the problems you new product will
solve.
2. Make sure your pre-launch page has a call
to action and encourages people to sign
up for your list.
3. Plan a simple pre-launch email campaign,
sending out emails to your list every week
or so - to keep them engaged. Share your

progress and other resources that would
be of interest to your ideal customer.
4. Ask your list and other followers to help
you spread the word.
5. Decide whether your product is best
suited to a big launch day, or a slow
launch and start to plan accordingly.

Chapter 9: We
launched! Now What?
On Sunday 31st May 2009 we quietly launched
Perch, late in the afternoon after returning home
from taking my daughter out for a birthday treat
with a friend. As the two girls amused themselves
we pushed Perch live and then emailed the 500
or so people who had signed up to our mailing
list with news of the release and a special offer
code. Over dinnertime the first sales started to
come in, by Monday afternoon the revenue from
sales had covered everything that we had spent
so far getting the product live - we were
profitable! We had no demo, so people were
buying Perch just based on a little video that
Drew had recorded for the homepage, and our
site was pretty simple - just designed by us as we

hadn’t put any money into the design of the site
or even the identity of the product as yet.
Adding Features
As we started to help people in support and talk
to our new customers we realised that other
people really did need this product too. It was
amazing to start to see people using Perch for
real live projects, and as they started to work
with Perch they also started to make feature
requests. A lot of feature requests.
Once you reach launch day, you might be hoping

you can relax for a while, however if your launch
has gone well and your product now has paying
customers you will find that things are about to
get even busier. If, like us, you have launched
with a small version of your product, the
minimum needed to make something that people
will buy, you are now going to get feature

requests coming in from your customers. As in
our case with Perch, the may have customers
happy to purchase your initial version but also
hoping that the things it currently doesn’t do will
soon be added. It is also likely that your
customers will start to request features you
hadn’t even thought about prior to launch and
you need a way to manage these and the
expectations of your growing customer base. In
this section I will give some advice for
negotiating your way through those first few
months as you start to find your feet as a product
owner.
Never put a date on anything
My top tip for bootstrappers and especially

people who are running a side project alongside
another job or business is to never announce
dates for things until the code is pretty much
ready to ship. With Perch we have always been

very aware that people are using the product in
their own business. We often get people asking
about whether a certain feature will be added and
when. If we agree that the feature should be
added we will say so, but we do not give an
indication of the date this will be ready. We don’t
want someone to buy a license or tell a client that
a certain feature will be available for their project,
only to find that we have pushed it back in our
planning. When we were also still doing
consultancy work as well as Perch, sometimes
Perch development had to slow down in order
that we could meet obligations to a client. Even
when we were working on Perch, we might start
looking at implementing some feature or
addition to the product and realise that actually it
was a bigger job than first thought. An add-on
would sometimes require updates to the API and
therefore to Perch Core. Had we promised a
release date we would have felt under pressure to
deliver for our customers and perhaps rushed

out the feature, without taking as much care with
it as we would like.
When customers press us for dates we explain

that we will only release features when we are
happy that they will not cause people problems,
and we don’t want to promise a date and then
have to backtrack on it as it may cause them
problems in terms of what they have offered to
clients. We explain that we understand if that
means they might have to use a different product
for that site - it’s a risk we have to take in order
to ensure that code that is released is good
quality.
In the same vein we don’t have any published

roadmap for Perch. Almost every time that we
think we have worked out what the next thing to
build will be, something comes up that is more
important. For example, when responsive design
became a big thing, and customers needed a way

to use responsive images in Perch, we stopped
what we were doing and implemented a solution.
We’re not tied to a fixed roadmap of feature
releases so are free to react to the things people
really want to use.
Collect use cases not feature requests
Customers will tend to request very specific

features. They will ask for exactly the thing that
they need for the current project that is open in
front of them. Your job as a product owner is to
turn those specific feature requests into
something general, something that will benefit
more than just this one customer. When a
customer makes a very specific request we ask
them what they are trying to achieve with that
feature, what is the general use case? We also
encourage people to post to the public forum
with their requests because then, if other

customers would find this feature useful too,
they may well add their thoughts.
If you add too many tiny, specific features to a

product it can become difficult to use and
bloated with things that are only useful to a small
minority. By outlining the problem a feature
request is aiming to solve you can often start to
see a more general solution that would solve the
issue for this customer but also add functionality
useful to other customers. The more you think in
this way the easier it becomes to start to see
these solutions as requests come in.
Quite frequently, once we understand the

problem the customer is trying to solve we find
that there is already a way to achieve the end
result in Perch. Although it might not be
completely perfect we can at least get the
customer most of the way there and we can look
at how to optimise the solution in a future

release. If you simply log the specific feature
request you can miss the chance to help the
customer explore how to create a solution now,
due to focussing on the fact that they can’t do it
in exactly the way they first envisaged.
Delight customers by solving their

problems
If a customer has logged a feature request that

you then go on to implement, make sure you
return to the forum, support ticket or email and
let them know that it is now available. Thank
them for their input in making your product
better for all the customers. Our experience is
that customers really love to see their ideas make
it into code, they feel part of what we are doing.
One of our favourite things is when someone
suggests something that is small and
straightforward enough to just add to the next
release. We try to do frequent code releases,

every so often someone will suggest a feature
one morning and we can then let them know in
the afternoon that it is available. This never
ceases to surprise and delight customers and is
fun to do.
Protect the core use case
In the case of Perch, the lightweight and minimal

nature of the product was a key selling point.
While adding features that customers wanted to
see, we had to take real care not to just end up
with the product expanding in every direction,
moving away from this idea of a small,
lightweight and simple CMS. We are now over
four years from launch, with version two of the
product, and that original basic use case is still
the same. Having a clear basic use case makes it
easier to reject features that will clutter the
product. It compells you to find alternate ways of
providing functionality so that it is available for

the people who will benefit from it and not get in
the way of those who are not interested. In our
case it is often the more complicated or technical
features that we need to consider carefully so
that they do not make Perch harder to use for
the web designer who does not know PHP and is
new to installing a CMS.
I believe that it is often easier for tiny teams to

protect the core use case than it is for larger
teams where a number of people are able to
commit code to the product. In our case Drew
McLellan owns Perch Core, he has final say over
what goes in and what stays out. Having a single
person looking after the core product ensures
that the code remains consistent and someone
has final say on the direction the product moves
in.

Make frequent, small releases - don’t
try to do too much at once
When we decided that we needed to launch

version two of Perch it was based on something
we were seeing in support, in increasing
numbers. We had optimised the Perch UI for
small sites, sites with maybe ten pages or so
however we were starting to see people with sites
that had 100 or more pages. Perch itself scaled
perfectly in terms of delivering the site content,
but the admin UI started to become stretched
and less usable for these larger sites. We planned
Perch 2 in a way that would enable people to
switch Perch into a mode that made it easier for
content editors when working on these larger
sites - yet still protected the simple use case.
With a Perch 2 on the horizon, and all of the

development work required for that, the upgrade
process, new documentation and upgrades to all

of our official apps we should have stopped
there. Instead we became very focussed on the
“big Perch 2 launch” and wanting to, at the same
time, completely revamp our marketing site and
other materials. We ended up with far too much
to do, making the whole launch quite stressful
and also later than we had hoped. We got
through it, and the launch itself was very
successful, but we learned a lesson about trying
to do all the things at once!
We now try to operate as much as possible via

incremental improvements across the product
and infrastructure. In terms of code, putting out
a release that contains fewer changes means that
there are fewer things to go wrong, fewer places
to investigate if a customer starts to report a
problem after upgrading. It also means we can
get features into the hands of our customers
more quickly, allowing us to do the sort of thing
I mentioned earlier - adding a feature request

quickly and pushing it out. If you are Software as
a Service this kind of deployment of changes is
far easier for you, you can push each change live
as soon as it is made and tested. In our case,
while the upgrade process is simple, we do have
to ask customers to update their software. If we
shipped a new release every day that might be
frustrating to people so we have found that
releasing every two weeks or so is a good balance
of not annoying customers with a constant nag
to update, and getting new code out in small
batches.
There will always be some changes that require

longer to implement, in 2013 we completely
rebuilt our demo system from the ground up and
moved from one very simple demo to three very
different demo sites. Getting those sites designed
and built and developing the system for
provisioning those demos was a lot of work.
However it at least was a defined project and

separate from other things we were doing with
the product, so we were able to keep chipping
away at that while also improving Perch itself.
Don’t be led astray by a noisy

minority
A final word of advice on features. For Perch we

only ever hear from around 25% of our
customers, and only 10% of people ever raise
more than one ticket in support. The customers
who regularly offer feedback, complain or
demand features are a tiny subset of customers.
The vast majority are buying license after license
but never get in touch with us. It is very easy to
feel as if everyone is requesting a certain feature,
when the reality is that one customer just asks for
it over and over again.
Sometimes, if you truly are protecting your core

use case, you will have to say no to feature

requests. The customers that really want that
feature won’t be happy but it is important to
make sure that your product is serving the
majority of customers and not a noisy minority.
The happy majority can often be completely
silent unless you actively seek out their opinion.
Even then, getting feedback from people who
are just happy with things as they are can be
difficult!
Balancing Client Work with

Your Product
As you begin to grow the customer base for your
product it will naturally start to take up more of
your time. Hopefully, you made the right pricing
decisions and are now able to assign time to the
product just as if it were another client. This is
essentially how we treated Perch during the four
year transition from being a client services

company to a product company. As the revenue
from Perch increased we were able to assign
more time to developing and supporting it.
You should also put some of the revenue from

your product back into developing it. We initially
launched with a site we had designed and with
stock illustration. One of the first things we did
when we saw that Perch was going to interest
people was to commission an illustrator and have
our bird character created, we also asked a
designer to redesign the marketing site. These
things were both incredibly valuable to our new
product and helped to raise the profile further.
As a hybrid product and services company the

hardest period to manage was when we hit
around 50/50 between client work and what we
knew we could justify financially dedicating to
Perch. By this time we were getting a reasonable
amount of support, which we wanted to respond

quickly to. Yet responding to support was then
creating an interruption and making it hard to
spend stretches of time doing client work. We
were also starting to find client work more
frustrating as we loved spending time on Perch
and realised that our goal at this point was to be
able to spend all of our time working on the
product.
I believe it is absolutely vital that you can treat

your product as a first class citizen alongside
your other projects. If you don’t treat it in this
way then it is likely that time you should be
spending on it will be absorbed by client work, it
is all too easy to push aside something you see as
an internal company project when clients are
demanding you do some additional work. If the
issue is that despite a growing customer base you
are finding that the product does not bring in
enough revenue to be treated as a first class
citizen then this would be a good time to start

assessing why. Are you pricing it too cheaply?
Are you reliant on an expensive service? Are you
attracting a type of customer who needs a lot of
handholding and so you find that most of the
time you should be spending on developing the
product is being burned up just doing support?
Identifying these problems early on gives you a
chance to fix them before they become a bigger
issue.
Marketing Your Product

Your initial push to get people interested in your
landing page and product launch was just the
start of the ongoing marketing that you will need
to do to keep bringing new customers to your
product. As a bootstrapper, you are unlikely to
have a huge amount of money to put into paid
acquisition of new customers, so you will need to
work hard at other tactics in order to spread the
word. For many designers and developers, this

side of business is hard and often not something
we have experience of. In our case we had been
fortunate enough as a service business to never
really need to advertise our services. Doing good
work and being generally visible in the industry
brought us enough clients to always have work to
keep busy. Our profiles in the industry helped us
find our initial batch of customers but after that,
we had to work out how to bring Perch to
customers who had not heard of Rachel Andrew
and Drew McLellan, and who were just looking
for a good CMS.
Content Marketing
You will hear a lot about content marketing in

the bootstrapping world, because writing content
is essentially free and we like things that are free!
Content marketing however isn’t simply about
writing a few blog posts, you need to have a
targeted and focussed approach to creating

content and consider the goals of spending the
time researching subjects and writing posts and
articles.
When thinking about using content marketing

you need to again consider your ideal customer.
What things - other than your product - might
they be interested in. As an example, my product
is a content management system, however I
don’t often write or speak about content
management. Our ideal customers are front-end
developers and designers, so I frequently write
and speak about issues relating to front-end web
development. It’s an area I know about and can
write about. Those articles then attract an
audience who I can talk to about our CMS - a
product aimed at that same market.
If you simply write about your own product,

then the writing will be interesting to people who
already use the product. That is valuable in other

ways such as educating existing customers, but it
is unlikely to work well in terms of marketing, as
you are, essentially, preaching to the choir.
Content Marketing for people who hate

writing
It is easy for me to advise content marketing, I

can’t have a thought without turning it into a
1000 word blog post! However, you might be
reading this and thinking that it is all very well
for someone who likes writing, but what if you
don’t? What if writing anything longer than a
tweet takes you a disproportionately long time, is
it still a good use of time? There are a number of
people who are highly successful using content
marketing despite not writing that content
themselves. In a December 2013 episode of the
Bootstrapped podcast the guest was Ruben
Gamez, he talks about how he uses outsourced
writers to create content for content marketing.

Paying for content is a perfectly legitimate
approach, and what Ruben is doing is not paying
for people to ghost write content, creating
content pretending to be him. He pays good
writers to create content under their own name -
and therefore not only benefits from the content
but also the following of the writer. This is a
clever technique. If your site is aimed at a
particular market, find writers who already have a
following in that market and pay them to write
for you. You will pay more if your writers are
known “names” with an existing following, but if
they wrote for you and then tweet or post to
their own blog about the piece, you will benefit
from their traffic who may well be outside of the
reach you personally have.
Sponsorship
It is quite common for products to sponsor

conferences and events that are relevant to their

industry. Depending on the industry and the
event these sponsor slots can range from the tens
to the thousands of dollars. As our product
targets designers and developers we have a whole
host of industry events to choose from, and from
quite early on event organisers began to contact
us to see if we would be interested in becoming a
sponsor.
With limited money available for advertising I

like the idea of spending that in a way that also
supports events that we love, however our
experience is that event sponsorship works best
if the package also includes a table to exhibit at
the event. We can then use the event as an
opportunity to chat to potential customers, see if
they have already heard about us, and find out
their opinions. We can also be set up with a
laptop and able to demonstrate to people the
answers to their questions about Perch. We tend
to find that where we just sponsor an event, with

our logo and name on the event program or on
the website, we see little return on that
investment.
The unlikely success of podcast sponsorship
This is likely to be industry specific, however

given that many readers may also be working on
products to target people in the web industry this
may well be useful. Our standout success in
terms of sponsorship has been our sponsorship
of podcasts. In particular those podcasts where
the hosts had already used Perch or were at least
aware of it as a good solution.
Paid Advertising
Paid advertising is my least favourite way of

marketing my product. I would much prefer to
spend money sponsoring things we like, that also
speak to our ideal customers. That said, it is

worth experimenting with, however as a
bootstrapper you will have limited funds so you
should spend them wisely.
Do not consider any kind of paid acquisition

until you have put some tracking in place and can
see if the advertising is leading to conversions.
How many clickthroughs you get is pretty
meaningless. The metric that matters is the
percentage that convert into paying customers or
at least are interested enough to signup for a trial
or demo. There is no point paying for it if you
cannot track it.
If you intend to try Adwords then, unless your

application is already very niche, you will want to
target the “long tail” keywords. These are the less
popular words or phrases that people may well
search on, rather than the obvious words that
describe your product. These will be less
expensive and may well send through more

highly targeted customers for your product as the
phrases used may better signify the intent of the
user. You will need to experiment with these,
which is where your conversion tracking comes
in.
We have had more success however in finding

specific sites to advertise on, as we can do some
research into the type of visitor that site gets, and
whether they are likely to be aligned with our
ideal customer. We use BuySellAds to find out
which sites run ads, and then look at the site in
question, read some articles and make a decision
as to how good a fit the articles on that site are.
We base that on whether they would be things
our ideal customer would find useful. Once the
ad is placed you should then again be tracking
performance in terms of conversions rather than
just looking at clicks. As you do this you will start
to get a feel for the types of content that convert
the best and there are some good deals to be had

if you target the smaller sites, with a specific
focus on your ideal customer.
Switching Focus
Our aim of selling a copy a day of Perch was
quickly surpassed however it took almost four
years before we were in a position to make the
break and declare ourselves a product company,
taking on no new client work. That decision has
meant a lot of change for us as a company, but
also in our personal lives - as we are a married
couple as well as business partners.
Becoming a product business means we no

longer have a separate office. We have no clients
visiting and so we were essentially paying for two
places for us to sit and work. In addition, the
international nature of our client base means that
working UK office hours 9–5 doesn’t really make
much sense. This has give us a new flexibility in

our own lives and we are currently in the process
of moving house to a much cheaper and nicer
location, as where we are physically located no
longer makes a lot of difference.
We are still learning how to work without the

deadlines and external pressure of client projects.
It is easy, when working on your own projects, to
become unstructured and fail to plan properly.
As you move from client-based project work to
being full time or most of the time on your own
products make sure you are also readdressing
your project management and working practices
to reflect the new reality.
Interview with Nathan Peretic
Another services company who announced they

were ceasing taking on client projects in 2013
was Full Stop, you might be familiar with their
side project that has now become their business -

United Pixelworkers. I saw several parallels
between Full Stop’s journey and ours and so
took the chance to have a chat with Nathan
Peretic, one of the founders of Full Stop and
United Pixelworkers to get his thoughts on the
transition.
Q. Did you intend United

Pixelworkers to become your full-
time business when you started it?
Absolutely not. When Jay and I opened

the doors to Full Stop, we had one big
client and one small client. That was
enough to pay the bills but not enough
to keep us busy. We started United
Pixelworkers on a whim. It was a
playground for us to try our hand at
retail and push the technology envelope
in a way we couldn’t on client projects.
Because it was moderately successful, we

slowly found ourselves treating it less like
a hobby and more like a small business.
Sometime after the first year or two we
realized we had inadvertently created
multiple businesses. It was around that
time we decided to register United
Pixelworkers officially as a business and
make plans for the most efficient way to
juggle it and Full Stop.
Cotton Bureau, however, was always

intended to be an independent, full-time
business for at least someone. The
growth of United Pixelworkers was
partially fueled by the partner tee
program we launched at the beginning of
2012. Every shirt until that point had
been designed by us or by a guest
designer. Once we started working with
A Book Apart, Rdio, Dribbble, et al, it
dawned on us that we should be making

t-shirts-as-a-service available to anyone
with a good enough design and the
willingness to tell a few friends. We
started planning Cotton Bureau in the
fall of 2012 with the intention of going
full-time on United Pixelworkers and
Cotton Bureau as soon as possible.
Because Cotton Bureau was just an idea
at the time, we decided to keep funding
its development by working with clients.
Most of 2013 was spent hemming and
hawing about whether to continue with
client work. We had fantastic clients and
more were knocking on our door every
day. In the end, we valued the personal
attention we wanted to give to United
Pixelworkers and Cotton Bureau too
highly to dilute it by also trying to spend
time with our first-born, Full Stop.
We’ve had a lot of conversations
internally about our personal strengths

and weaknesses. While it would have
been nice to push all three businesses
forward, it’s just not who we are.
Q. What were the biggest challenges

in mixing a successful product
business with client work?
Our process, if you can call it that, has

always been ad hoc. With two founders
(three owners), each of whom have
radically different personalities, finding a
one-size-fits-all method is impossible.
We’ve been fortunate that from our first
job we were highly selective about the
people with whom we worked. Any red
flags were grounds for rejecting a
potential project. We’re proud that in
four years we only accepted one or two
projects that resulted in any turbulence.
For us, mixing products and clients has

been about communication and fairness.
We worked at the client’s speed and
found time for our products on the side.
It wasn’t easy, particularly, as the side
products grew in size and complexity,
but we always found that the techniques
we picked up working on one side of the
house found creative and effective uses
on the other. Our clients appreciated the
knowledge we had earned from working
directly with customers and building
highly modern websites. In turn, we were
exposed to many industries and business
models that informed our own product
development. It was certainly
challenging, but it was equally rewarding.
Q. Was there a particular moment

that triggered the decision to make
the leap into full-time on the product?

Yep. Our company was launched on the
back of a pretty sizable job. Back then,
we’d made an arrangement with our
former employer to take care of a client
that we had a pretty good relationship
with. In exchange, we let them keep a big
chunk of the money. This client had
been in maintenance mode for a few
years but was now coming back with
twice the original budget and this time it
would all go to us. We’d spent the
intervening time working with startups
and small businesses and restaurants and
non-profits, essentially we’d limited
ourselves to projects where we could
work directly with the decision makers.
In all that time, we didn’t fill out a single
RFP. When our biggest and favorite
client was ready to begin round two, we
weren’t thrilled with going down that
road, but they had their regulations so we

fell into line. As it turned out, every
instinct we had was confirmed. The RFP
process is still completely broken. In
spite of being the company that had
maintained the site for the past three
years and having a tremendous
relationship with the web and executive
teams and despite having every forward-
thinking technical decision we had made
in 2010 validated by the course of events,
another company was selected for the
job. In order to clear our schedule, we
had been declining new opportunities for
months. We were left quite suddenly
with the need to either round up a fresh
batch of clients or accept the new
financial and organizational reality.
Despite having half-a-dozen promising
client leads, it barely took five minutes of
conversation to agree that the best
course for our company was to go

forward with our products quickly and
enthusiastically. We made this decision
about three weeks ago (early November
2013). The ends haven’t quite begun to
meet, but every day makes it abundantly
clear this was the right move. We’re
thrilled to finally be able to give our full
attention to our customers.
Q. Has it been difficult to end

relationships with ongoing clients?
It’s a work-in-progress. We didn’t do a

lot of maintenance, so all of our past
clients are well-positioned to move
forward without us. We’re currently
wrapping up our last two client projects.
They’ll each have excellent foundations
when we’re finished including a CMS to
make any necessary modifications for the
foreseeable future. Our business has

always been about walking a client
through the business needs of a site and
creating unique designs. Since those parts
have already been completed, finding
someone with basic maintenance skills to
apply CMS updates or make minor
revisions should be relatively easy.
Q. Do you think this will mean a

change in the way you work/your
lifestyle generally? For example we
got rid of our external office and
moved back to working from home
when we stopped working with
clients.
For sure. Our current office is a nicely

restored warehouse in the Pittsburgh
Strip district. We originally leased it
because we need somewhere central and
somewhere we could invite clients. It’s a

beautiful space, and we thoroughly
enjoyed our three years there. With the
demands of carrying physical products,
however, we’ve recently begun to
outgrow that space. A lot of the niceties
we acquired for the office also don’t
make a whole lot of sense outside the
arena of client services. Our lease is up in
July (six months from now), so we’ll
probably begin shopping for a slightly
cheaper, bigger space in the same general
area. We’ve also had a lot of time to
reflect on our working environment over
the years. I suspect we’ll be making some
changes to how things look and feel just
because our preferences have changed in
addition to our needs.
Besides the changes of mixing digital and

analog, we’re also going to be feeling the
effects of the change to the business

model and deployment cycles. A
traditional client services shop sees big
chunks of money arriving sporadically.
Having a product means regular revenue
with occasional spikes and troughs. The
regularity is a tremendous boon for
planning. Having a product also makes
partitioning jobs significantly easier. If
customer service becomes too
overwhelming for one person, we can
bring in a second, part-time person to
share the load. That’s a much bigger
riddle in design, development, project
management, etc. Because we’ve
balanced our products and clients for the
past few years, we already know what it’s
like to release and iterate. Going full-time
is going to speed up that entire process
for us. More features, more refinement,
more time to measure and evaluate and
enhance. No matter how iterative and

gradual a process you include in a client
project, the day always comes when the
money runs out, the team is reassigned
or the client goes in a new direction.
Internally, these decisions are now
entirely under our control. We’re the
ones who decide what to do, and the
only people we need to persuade are
each other.
Q. What do you think you will miss

about client work?
It’s always a pleasure to meet new clients,

to have a chance for a fresh start, to visit
a place you’ve never seen, to make an
impact on someone else’s business. Also,
the money. The money was good for us.
We’d built up enough of a reputation for
top-notch work that we could charge fair
rates and have our choice of projects.

We’ll eventually surpass our client profits
with product profits, but there’s
definitely a sacrifice both in the short-
term and the long-term. We could have
hired out the client work and cashed in
on our name. We very deliberately chose
not to do that. Full Stop has always had a
loudly proclaimed set of principles for
client work. That doesn’t change now.
We have new principles that apply to our
new business, but the old principles
haven’t gone away. If we couldn’t do it
the way we wanted to do it, we wouldn’t
do it at all.
I can also tell you what we won’t miss

about client work. We won’t miss the
deadlines. We won’t miss the cycle of
having the same sales conversations and
kickoff conversations and design
conversations and development

conversations and launch conversations
and maintenance conversations. We
won’t miss having to explain what
responsive design is and why it’s not
important to support Internet Explorer 7
and the difference between well-
structured content and unstructured
content. We won’t miss client meetings
and proposals and contracts and file
handoffs. We left our jobs four years ago
because the environment we were in was
toxic. We resolved to do it better, to be a
lighthouse in Pittsburgh for good design
and good business. We did that. What we
found along the way is that merely
reforming client services didn’t change
the fact that we were still doing client
services. We have tremendous respect
for the companies that dedicate
themselves to helping clients. The need
for people to do that job is only growing.

For us, however, we’d climbed the
mountain and were disappointed by the
view. We’re going to spend the next few
years exploring some new territory. We’ll
let you know what we find.
Enjoy the Journey

Your side project may just be a small part of your
company revenue or personal income, or may
grow into your full-time job. Whatever happens
in the next few months or years, my experience
tells me that through launching your own
product, you will find that you learn skills that
will help you in all aspects of your business and
career.
For us, Perch enabled us to have complete

control over a project and product. We were
used to helping clients with their businesses, to
giving advice that often was not acted upon, with

Perch we had a chance to try things for
ourselves. We could make our own mistakes and
learn from them, continually trying to improve
the product, our message and marketing. We are
still learning today, and I find it as exciting and
interesting as I did the day after we launched.
We really enjoy the fact that we are in direct

contact with the people who use our product.
We get to see first hand when it works for them,
and how happy they are when we add a longed
for feature or show them how to achieve
something they need to do through the product.
We also get to experience their frustrations in
support, and have had to learn how to keep our
own irritation in check and try to get to the
bottom of the problem that this customer sees,
find out how we can best help them to have a
good experience.

Launching your own, bootstrapped side project
will be hard work. I am writing these closing
words in the break between Christmas and New
Year, wanting to release this book trumped
holiday time off for me in 2013. The work is
always worth it and launching is just the
beginning of your journey.
Let me know how you get on.
Rachel Andrew

The Profitable Side Project

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

The Profitable Side Project

Uploaded by

Copyright:

Available Formats

The Profitable Side Project

a practical guide to developing a product business

The Profitable Side Project Handbook 1

2 The Profitable Side Project Handbook

The Profitable Side Project Handbook 3

4 The Profitable Side Project Handbook

The Profitable Side Project Handbook 5

6 The Profitable Side Project Handbook

Developing your own product means that,

The Profitable Side Project Handbook 7

It is possible to get many of these additional

8 The Profitable Side Project Handbook

It isn’t surprising that people feel this way. We’re

The Profitable Side Project Handbook 9

Therefore I really do believe that many decent

10 The Profitable Side Project Handbook

What defines success for your

The Profitable Side Project Handbook 11

Ultimately Perch surpassed our expectations,

Getting to the Shipping Point

12 The Profitable Side Project Handbook

“The goal of a startup is to find the

The funded startup may well have the luxury of

The Profitable Side Project Handbook 13

Perch launched as a paid version from the outset.

14 The Profitable Side Project Handbook

Perch was developed over about four weekends,

Although we continue to have great success with

The Profitable Side Project Handbook 15

16 The Profitable Side Project Handbook

Ultimately we gave up on it. Our interest and

The Profitable Side Project Handbook 17

Taking time to consider your infrastructure, even

18 The Profitable Side Project Handbook

As we will consider when we talk about pricing

The Profitable Side Project Handbook 19

Own your customers and data

On the subject of using third party services to get

20 The Profitable Side Project Handbook

The data that you store about customers and

The Profitable Side Project Handbook 21

Small Things Can Grow

22 The Profitable Side Project Handbook

Take Action: First Steps to

The Profitable Side Project Handbook 23

1. Imagine yourself one year on from

2. What can you remove from your product

24 The Profitable Side Project Handbook

The Profitable Side Project Handbook 25

Software as a Service (SAAS)

To someone considering launching a product the

26 The Profitable Side Project Handbook

Control of the environment

In a SaaS business you host the software on your

Control over the environment also makes fixing

The Profitable Side Project Handbook 27

Having this control over the environment does

28 The Profitable Side Project Handbook

Control of the customer

In addition to be able to help customers easily

The Profitable Side Project Handbook 29

Right from the point at which a potential