Learn10 Vital Lessons for Web Start-Ups

Treehouse
writes on August 19, 2009

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.

0 Responses to “10 Vital Lessons for Web Start-Ups”

  1. Hi, I never realized you guys we in Bath, If ever I get some complex web work come up, maybe I should give you guys a shout, I can only do static stuff, so any dynamic work I may be able to shove your way. Matt.

  2. Increasinglyunfortunately on December 5, 2009 at 10:24 pm said:

    Sing Troop,improve fruit open blue involve career against fear often modern memory foreign species appointment cover village criterion between suddenly audience west leadership deliver wear else good to bed advise someone partly demand authority phone merely different true light mental while weather passage base observe surface farmer commit face theory complex product understanding centre ride technical legislation asset race standard dream provide conservative chemical believe key issue protection rest sister like cos main belief housing life particularly drop all expert initiative heat truth employment top chance scene grant operate league

  3. Great info. The information relating to the payment processing was helpful to me and my fledgling web start-up.

  4. I wish had seen this article when I first started. it would have saved me a lott of gried

  5. Thanks for nice posting for startups companies which caters to product development. I will keep reading your future articles…….

  6. I just wanted to say thank for a great article. I am getting ready to launch a business and I found a lot of useful information in here. I have been so upside down trying to figure out what to do next, and this article has convinced me that building a business from the ground up doesn’t necessarily mean you have to do it all yourself…

  7. Thanks for educational post

  8. Wow! Some really great advice here! I’m currently in learning process of these things, but at some point I plan to launch my web app too. Hope it works well! 🙂

  9. Thanks for this article. As a start up myself, I know how much of it rings true!
    The item that really stuck out for me was #3 – about customer support. Most of the other items are internal issues or at least fairly transparent to the client, whereas customer support is always vital and can win or lose you further business and, more importantly, word of mouth recommendations. Cheers, @deltacubed.

  10. I so agree with you about #10 Hire in the Experts. I started writing http://www.OpenYourDiary.com on my own partly to learn Ruby on Rails but really to cut costs. While this worked, I discovered that hiring a couple of Russian freelancers via oDesk got things moving a lot faster and to a far higher standard. It also gave me time to work on the other sides of the business.

  11. Syd Salmon on August 20, 2009 at 6:40 pm said:

    Thanks for sharing your insights. The payment provider discussion was especially useful for me.

  12. Hi Drew, congratulations and thank you for a great share. I am also working on launching a twitter app and was wondering if you can talk more about your launch strategy. Ok, you have a good product but how did you launch it? Did you start out using a blog , invite bloggers to beta or just do the old Pr and customers start coming…..

    I am looking to learn and thanks for sharing.

    Ola
    @mytweetdine

  13. Thank you for share your experiences.

  14. I’m going to have to disagree with you about adding more CMS’s to the vast pool out there. There comes a time when enough is enough. The last thing we need is another CMS or Project management tool in the market. I think it’s very natural for web development companies to offer their CMS or CRM as a paid product because it’s already built and works well in house. The problem with CMS’s and CRM’s is that every organizations work flow varies so greatly that its impossible to be all things to all companies.

    There are lots of other problems to solve and interesting tools to create out there and I just shake my head when I see yet another CRM or CMS. That’s not to say that I don’t think that CMS’ have room to grow – the holy grail would be a CMS that Mom and Pop can design a slick looking website with. That’s a long ways off, though, and most of the CMS’ I see being created these days are basically the exact same as everything else. Maybe HTML5 will change things, who knows. Anyways, that’s my two cents. The advice in this post is solid, otherwise.

    • The sort of Mom and Pop-friendly CMS you dream of will always be a long way off if we all stop innovating and moving CMSs forward. If the solutions out there don’t meet certain needs, then there’s a market for a product in that same category that does meet those needs.

      • “That’s not to say that I don’t think that CMS’ have room to grow”

        I acknowledge this, but what I’m saying is that in general, most CMS’ are pretty similar these days. I’ve yet to see something truly innovative in a long time. Just sayin’..

  15. That’s a great article, thanks Drew! Especially your advice on #1 payment providers and #2 invoicing systems touches (important!) issues too few start-ups really think through up front.

    I’d like to add that you should a) really dive into all legal stuff that might be required. Depending on your country, there might be lots of regulations on invoices and tax issues. b) Automation is key: development time on automating payment processing, sending invoices, supervising open payments / returned direct debits etc. is perfectly spent.

  16. Interesting reading – on the subject of make it easy for customers to send in feedback – you could always use third-party plugins like Get Satisfaction and Kampyle. You would also do good to start an email list to reach out to your customers (like an autoresponder), and you may need a help desk/support ticket solution depending on your line of biz. These can provide a sense of community (then you could advance to a stage where you have forums on your site for community support). The ternary principles for guiding a successful startup would be patience, perseverance and continuous evolution.
    On this topic, the following reading might be useful
    Presentation – How I founded, grew and sold my web startups – http://www.slideshare.net/cmercier/how-i-founded-bootstrapped-grew-and-sold-my-web-startups-meshu-2009

    You dont seem to have mentioned anything about lessons in public relations (PR).
    P.R. Rules in Silicon Valley startups – http://mohanarun.com/09-aug-2009/

  17. Awesome article. Offers a bunch of advice I’ll be making use of at prentnow.com 🙂
    @carsonified I’ll be here everyday if you keep articles like this popping up everyday

  18. I admire your blogs site, its nice, and I love this article.

  19. Just wondering, why are you testing mysql insertion, deletion, etc? Is it not sufficient that the mysql extension is enabled? Seems unnecessary?

    • Our server compatibility test suite checks for all the major functionality that Perch needs.

      It’s perfectly possible to have a MySQL user account that is configured to only allow e.g. SELECTs, which isn’t sufficient. So we check for INSERTs, UPDATEs and DELETEs too, as these are all used by the software.

  20. I’m interested in starting something similar. Can you tell me what you do to protect your PHP code? How does the license key verification work?

    Thanks.

    • We don’t obfuscate or encrypt the PHP at all, as this could make the software less useful for some people. License keys are attached to domains (one ‘live’ one testing/dev) which are verified at log in.

  21. This is one of the best articles I have ever read regarding start-ups. GREAT job! Thanks for the information and taking the time to share….

  22. A great explanation with some good pointers. I would like to think that the testers helped the development of the CMS though.

    A great little CMS however, and something that I think was very much needed.

    • Testers did help the development, big time. We would have been lost without those who stepped up and helped us out with getting the software running well in the real world.

      That’s almost a post in itself, however. One I think I’ll have to write up.

  23. Great article and some really good advice. One question: Obviously law is not my expertise, but what are the pros/cons of getting a software license? Getting a lawyer in sounds expensive!

    • You need a license that says what the customer is or is not allowed to do with the software, what is expected of the customer and what will be supplied by you as the vendor.

      Legal help isn’t always expensive. Things like licenses are nearly off-the-shelf. I think we paid a few hundred GBP.

Leave a Reply

You must be logged in to post a comment.

Learning to code can be fun!

Get started today with a free trial and discover why thousands of students are choosing Treehouse to learn about web development, design, and business.

Learn more