Blog:

This summer we launched Perch as a side project from our web development agency, edgeofmyseat.com. Perch is a really little content management system aimed at web designers who want to enable their clients to update their own site content. As this is our first product (we normally work on website projects for design agencies), there were quite a lot of new things for us to learn.

In this post I’ll cover some of the things we’ve learned along the way. Whilst the same lessons won’t apply completely to every situation, they’ll be interesting to anyone thinking about launching a web app.

#1 Choose Your Payment Provider Carefully

Rather than operating as a hosted service, Perch is a PHP app that you download and install as part of your own website. As such, we’d be selling it from our site via electronic delivery. We decided pretty early on that we were going to sell Perch using PayPal. As our target customers are web designers, we figured that most designers would be familiar with PayPal and probably already have an account. What’s more, it would be easy to integrate into our checkout, still allows customers to pay with a credit card, and there are no up-front fees involved.

That last point was important, as one of our business decisions with Perch was that we wanted the project to fund itself. Although being born out of a profitable existing business, we wanted to bootstrap Perch as much as possible, so paying a fee for each transaction but nothing up-front suited us just fine. The downside of this is that the fee per transaction is higher than it would be with traditional credit card processing, so there comes a point whereby you’re doing enough credit card business through PayPal that it’s more profitable to pay for the merchant account and payment gateway.

For Perch, about one third of our payments are with a credit card via PayPal, so we certainly need keep an eye on the figures to make sure we’re getting the most cost effective deal on the processing fees.

#2 Know How You’re Going to Deal with Invoicing

As a web development agency, we work alongside design agencies building content managed websites and online stores, and typically only deal with a handful of larger invoices each month. However, with Perch we quickly found that we would be facing hundreds of invoices that would all need to be created in our accounts system by hand.

We use the online accounting software Xero for all our accounts, and found that this had a couple of features that would save the day and enable us to handle the volume of invoices more easily. Firstly, we discovered that Xero can import transactions from PayPal just like any other bank account. Once an hour the software updates showing all the new payments that have come in, ready to be matched up with invoices.

Those invoices are the second half of the problem. Fortunately, Xero has a RESTful API that would enable us to programatically create each customer and invoice in our accounts directly from our web server. This is great, because it means that within about a minute of each sale we’ve got the customer and their invoice set up in Xero, and then within the hour the PayPal transaction appears, ready to be matched up. The only manual part is the matching up, which is very quick to do.

Using an API to manipulate your business accounts can sound a bit daunting at first, but Xero have a good testing platform to develop against, and our integration was manually checked over before we could go live to make sure that we weren’t doing anything stupid.

#3 Be Super-Organised with Customer Support

Another new area for us was dealing with end-user support. We were fairly sure we wanted to do this out in public on some sort of forum rather than in email. We felt it was important that customers could search past discussions before posting in case their question had already been answered.

After looking around at a few different solutions, we discovered Tender, which seemed to do what we wanted. Crucially, they had an option to point a subdomain at their server so that we could use support.grabaperch.com for our site. This also meant that we could share cookies between our customer account system and the support system on Tender, meaning that, with a quick bit of integration, customers can access both systems with one account.

One thing we didn’t quite appreciate up front was the distinction between discussion and support. Anything posted to Tender is flagged and requires a response from our team, which is great when customers have issues they need our help resolving. This means that nothing gets missed and on average all support requests are dealt with in under one hour.

This isn’t so great for general discussion between users, as the environment appears to discourage discussion, as every post is implicitly requesting a formal response. As a reaction to this we’ve just set up a separate community discussion forum where customers can chat and share ideas. We’ll see how that goes – our one concern is that customers will be unsure where they should be posting for help.

#4 Provide a Demo

One thing we’d seen with other CMS products is the pitifully sad online demo where the login details are published and anyone can go in and have a play. We always felt that the customer experience was pretty bad with these, as each customer ends up looking at a CMS full for everyone else’s test junk. Also, with Perch being designed for small sites, the likelihood of two customers being logged in and attempting to edit the same page at once was fairly high. As soon as that happens the appearance would be that the CMS is behaving erratically. Not good!

Because of this, we decided we didn’t want an online demo and launched the product without one. Customer feedback quickly told us that that wasn’t going to be good enough, so we had to go back to the drawing board. We were still convinced that a shared online demo would suck, so we decided to provide each customer with their own unique install of Perch to play with.

We built a system that enables customers to sign up for a demo. This then automatically installs a new copy of Perch for them and emails the customer their access details. This way, each customer can try the system out without all the usual disadvantages of a shared system.

#5 Make it Easy for Customers to Send Feedback

At the end of the demo process (each demo site runs for 24 hours) we send the customer an email to thank them for trying out Perch. We thought that this was a great opportunity to find out what they thought of the software. We added the following to the email and hoped for the best.

Loved it? Hated it? One crucial thing missing? Hit reply and let us know – we’ll use your feedback to make Perch better.

Turns out that this was one of the smartest things we did. Asking a customer to just hit reply and talk to us made it so easy for people to respond that more than 25% of customers did just that. We could quickly answer any questions, and most importantly, that we are able to catch those who decided not to buy because they thought Perch was missing a feature that they’d just not spotted. For those who ultimately did walk away, we were able to get an idea of why they chose not to use Perch and we can use that to inform future product decisions.

#6 Just because a Market’s busy, Doesn’t Mean it’s Saturated

At some points, we’ve stopped to think twice about launching yet another content management system product into the market. There are so many different systems out there, commercial and open source, small and large. The reason that there are so many options is that content management is an extremely broad area, with lots of different customer requirements. What’s more, almost everyone with a website is a potential customer for some sort of CMS of some description, and there’s certainly no shortage of people with websites.

It’s very tempting to be put off from lunching something just because there are already other products that do a similar job. It’s important to remember that it’s not only the job you do, but how you do it that counts. If your product can offer something different, be that in user experience, a way of working, unusual features, or specialisation for a role or industry, then they’ll be some kind of market for it. There are millions of customers out there. All you need to do is figure out if the potential market is big enough to support your plans.

#7 Don’t Worry About the Dinosaurs

Right from the start we were sure that Perch had to be built in PHP, as customers would need to be able to get the CMS running easily on their own hosting. PHP is rock solid and super-easy to host. One concern we had was that although PHP5 has been around for ages, there are still a lot of servers out there running PHP4 even though it’s no longer supported. Projects like WordPress have a goal of being able to run anywhere, and as such stick to the parts of the language only available in PHP4.

As a company, we develop primarily in object-oriented PHP5, and knowing all the advantages that well structured OO code brings, I was reluctant to develop a new app in crufty old PHP4 code. We played with the idea of having two versions, but that meant twice the work on new features and twice the bugs to fix. So we just took the plunge and made the app PHP5 only, thinking that we’d wait and see if there was any demand for a PHP4 version.

As it turns out, it’s been a complete non-issue. On the occasion when a customer has found their hosting is PHP4, they’ve been able to contact their hosting company and get the site switched to PHP5. It’s all surprisingly low-hassle. Turns out we were worrying about a problem that didn’t even exist.

#8 Release Early and Often, but Plan Ahead

We often hear the phrase “release early, release often”, but what does that really mean? For us, it meant getting our initial release of Perch to a point where it had just enough functionality to be useful and stopping there and shipping. From a development point of view, releases force you to get bugs tied down, loose ends tied up and get everything properly tested. So a shipping release is a known stable point in where everything is 100% solid and functional. Incrementally adding new features on top of a release then becomes a more reliable process and it’s much easier to keep your application stable.

When we were building the initial version of Perch I had a whole list of ideas of what features we’d build into 1.1, 1.2 and so on. It’s great that we released early, as it turns out that none of the features I thought were essential have been asked for by customers. I thought we’d need RSS – no one cares about RSS for a small site.

So whilst you don’t want to spend loads of time building in features before you ship, it is still important to plan ahead and leave doors open for the features you may wish to add further down the line. With Perch, I figured it might be good to have the option of translating the admin interface into different languages. I didn’t have a specific plan for how it would work, and certainly didn’t spend time building it, but what I did do was make sure that every piece of text in the interface was passed through a translation function.

At the time we launched, my PerchLang::get() function calls just returned whatever string was passed to them – the function basically did nothing. But it did mean that when I came to implementing translations in version 1.1.5, all I had to do was think of the best way to take a string in English and find the translated version. At the time of writing, Perch is available in 12 customer-contributed languages from Russian to Portuguese, with minimal programming needed.

#9 Make Full use of Existing Tools

What no one tells you when you launch a product is that about 50% of your effort goes into developing the product, and the other 50% is putting infrastructure in place to market, sell and support it. There’s a lot of work that goes into all the peripheral systems needed, and I think we’d have given up if we tried to implement all that ourselves.

Instead we made use of PayPal to take funds, Tender to handle the support, we asked people to follow us on Twitter to keep in touch rather than setting up some kind of mailing system. We’ve set up our discussion forums using bbPress. Anywhere where we can make use of an existing solution instead of writing our own, we’ve tried to do so. Not only does it work out more cost effective, it enables us to focus on our main task – building a useful product.

#10 Hire in the Experts

First and foremost, we’re web developers. That means there are parts of a project that we’ll be good at, but there are going to be parts that are outside our expertise. One thing we’ve learned is that it’s really important to call in the experts to help cover your weak spots.

The first experts we called in were our solicitors to draft up a professional software license agreement. We could have probably come up with something ourselves, but the chances are that when it came to the crunch it wouldn’t stand up in a court of law and therefore would be worthless. We hope that we never have to test our license in court, but there’s no point in having a cobbled together legal document of any kind – it’s as good as having none.

The next job that called for experts was with the interface design. We like to think we know one end of a usable interface from the other, but when it comes to the crunch it’s not our core skill. We wanted the UI for Perch to be really well considered, easy to use and something that designers would be happy to hand over to their clients to use. So we called on the help of our friends at Nine Four who were able to take our jumbled prototype UI and turn it into something that really worked.

When we launched our marketing site, still trying to not spend money we didn’t need to spend, we bought some stock illustration from iStockPhoto and just ran with it. This was nice and cheap, but long term is was fairly charmless and we didn’t think it wise to build up a brand around illustration that wasn’t technically ours. So shortly after launching, we hired illustrator Kev Adamson to develop some original illustrations that we could use going forward. The great thing is that now not only is the illustration a thousand times better than what we had from stock, we have someone to go back to for any further work we need doing.

As an agency we’d be horrified if our customers thought they’d do their web development themselves instead of calling us in to do it properly. We’ve tried to apply the same principal to our own project and call in experts where they can help.

In Conclusion

Of course these are not universal rules, but they are fairly broad lessons that we’ve learned on our journey so far. Some we knew in theory and have put into practice, and others we’ve picked up along the way. I’m sure as we carry on down the road there’ll be plenty more to learn. Perhaps you’ve had similar – or contrary – experiences, if so leave a comment and tell us about it. And if you ever build small sites for clients, family or organisations you care about, perhaps you’ll come and check us out.