March 23, 2017

Building an online webapp business… what could possibly go wrong?

Heard about Beetrieve?

Of course you haven’t. Too bad, because I spent years of hard work building it to take on SurveyMonkey and PollDaddy. Heard of them then? Yeah, I thought so.

There are a lot of advice write-ups floating around on how to start your business. What to do, how to get funding. What to avoid doing. And success stories, of course. Founders who have managed to break out and grow their businesses.

This is not that kind of article. I built a business that ultimately failed, despite my at-the-time best effort. So here I will just focus on my personal experience. The things I now understand I did wrong. What I did right as well, but why it ultimately failed still. Maybe, since these are lessons straight from the horse’s mouth, they will resonate and help you avoid the same mistakes.

Failures like these are often swept under the carpet and forgotten, especially by the people who fail. But they should be celebrated; you learn so much more from failures, especially long-winded ones, than from successes. The lessons certainly were invaluable for me in my current job and will continue to be in any future endeavours.

Why did I start?

(If you’re impatient and just want to find out why it failed, by all means skip this section.)

I’ve always wanted to create stuff myself. Around 2006-2007 I found myself in a job that didn’t allow much of that creativity though. I felt it was time to take my tinkering on the side to the next level and try to grow an IT business beside the job, something that could become big.

My brother at the time worked for a big research agency which did projects for NGOs and government bodies to measure impacts of various programs by sending out email-invitations to online surveys to a large number of participants, then analyze the answers.
He would complain a lot about the software they used for setting up and conducting these surveys: It was slow, confusing and error-prone. Interestingly it was supplied by a big international software company that should be able to do better.

Well, I knew I could… much better! I had just returned from that year’s Apple Worldwide Developer Conference in San Francisco, where I’d been fired up about AJAX, which were if not entirely new, certainly newish and hot then. AJAX is the foundation technology that allows a web page to update its contents without a complete page reload. Now taken for granted with Facebook, WhatsApp Web and lots of other web content; in 2007 an ongoing revolution that allowed web pages to behave more like desktop applications.

I realized that with what I knew I could probably build an online survey and poll application for the browser that would outshine all others on the market, as they were built on older, more rigid frameworks and mindsets. The time to build a modern, AJAX-centric webapp for the prosumer and enterprise was NOW!

It looked like the perfect storm of wants and needs. I was looking to build an online business. The time was ideal to build a next generation web app. I had lots of knowledge in the space, and could teach myself what I didn’t know. My brother was an expert in the kind of application we needed and could advice on functionality and user interface.

So we went to work. I created literally everything. I got my hands on some old computers and sat up a mini-cluster at home, connected to my ADSL line. It hosted the web server, the app server and the database server. I taught myself how to build and configure it all properly, with database replication and redundancy and load balancing. I designed and redesigned (and redesigned and redesigned) the user interface, the graphics, and web pages. I wrote user manuals and reference documentation.
But most of all I programmed the webapp. I spent every free moment and sat long into the night coding, over a couple of years. What little social life I had vanished as the application took shape. I knew part of the coding stack needed already, the behind-the-scene part, and taught myself object-oriented Javascript and then the AJAX foundations from scratch, to build the user-facing parts.

The Beetrieve User interface

I also got great help from a couple of good friends who ran and still runs a successful development consultancy company to inject capital into the now incorporated company and be board members. It looked good.

Version 1.0 of the software debuted in the summer of 2008. By 2012 we were up to version 3.0, then 3.1. We had moved it from self-hosting to running on Amazon’s cloud platform. The web app was definitively really good (in my own humble opinion), had hundreds of users which had created and conducted thousands of surveys and polls, some of them very large.

Using Beetrieve (See also Working with participants in Beetrieve)

Around New Year 2015-2016 we shut it down because there was no more money in the till and we couldn’t pay the bills.

What I did wrong

How could that happen? Looking back it actually seems unavoidable, but maybe that’s how hindsight always works. I could not have been successful the way I did things, or NOT did things. Let’s look at the reasons.

Perhaps the biggest mistake I made was to focus too much on the building of the product.

I’m an introvert person by nature, and coding was so fun and satisfyingly intense and narrowly focused that I “hid behind the code” because it was the place I felt most comfortable.

I thought ‘Build it and they will come’ actually was a thing. It isn’t. Ok, maybe in a little place called Silicon Valley, where founders and entrepreneurs are hyper-connected (both in the 1’s and 0’s sense and and the people sense) and which is chock full of over-eager early adopters. Other places, basically forget it.

What I should have forced myself to do was to spend much more time, even at the expense of feature development, on marketing and selling the product. I should have forced myself to network and nurturing relationships with possible clients, even cold-calling them.

And I should have done this over and over again. It’s a repetition exercise because most of the time, your efforts leads nowhere. But you slowly become better at it. I tried a couple of times, without success, but gave up too quickly.

A related mistake was to use the money we had for building the product instead of on marketing. We were definitively a lean startup, and the amount of capital we initially got from the buddy investors was well below $50000. The setup and initial investment costs were very small, which is a good thing. I ran it from home. I got old hardware to run it on more or less for free. I bought a development computer, an office chair and desk and not much more. The running costs were also very modest, given the setup.

Still, in reality we saved ourselves to bankruptcy. I felt that hiring a pro marketing and sales force would be in opposition to the ‘lean startup’ idea, and of course it would deplete our budget quickly. There was also that feeling of ‘we just have to implement that one more needed feature’ before it’s good enough to truly market to professionals.

In the end, all just bad excuses for not taking definite steps that might have burned cash in the short term, but that at least would have added professionals in marketing and sales to our company to show us nerds how it’s done, and given us a chance to sell the application to enough customers to get get a good revenue stream going.

Another obvious mistake was to not define and focus on the market we wanted to capture.

We found ourselves in a difficult middle-ground. As the obvious international low-end player, with a free/cheap product with massive volume, we had SurveyMonkey. But on the national level, very different but also a survey product competitor, there was another big player, a company called QuestBack. Their model was to use a sales and consultancy team directly selling and consulting in the enterprise market. Their online web survey product was just a tool in their value chain. They obviously had a lot fewer clients than SurveyMonkey, but extracted a hefty annual subscription fee from the clients they had, to the tune of, we learned, somewhere in the $10 000 – $30 0000 landscape.

We felt we had a product that could stand well against both these players. User friendliness and feature competitive against SurveyMonkey; the same, plus much much lower cost, against QuestBack. So we ended up trying to build and price our product to compete against both of them.

In retrospect, we should have focused intensely on taking on QuestBack’s market segment. It operated on our home turf, where we could focus our salesmanship. With our low running costs, if we had managed to convince just a small percentage of the reasonably big enterprise existing- or potential-customers of QuestBack to use our system we would be gold.

Our advantage play would be much lower cost, and a product that would be so easy and self-explanatory to use that no big support and consultancy team would actually be needed. This should be an attractive preposition to *some* of these entities, those that had some competency in-house running surveys, but needed the right tool for the job. They would then not have to pay the price QuestBack took for the team of sales and consultancy people it staffed.

Here it has to be mentioned that I didn’t understand the enterprise market very well at all. Steve Jobs famously said that he loved the consumer market, because it was so transparent: consumers vote with their wallets. If they like your product, they will buy it.

The enterprise segment is more opaque, because the people who make purchase decisions are not the users. Instead, the purchasers make their decisions based on a set of criteria that is often tangential to whether the product is the best to use or the most cost effective. For instance, a person making a purchase decision is more likely to go for a big well-known company even if that company is much more expensive. It’s not the purchaser’s own money anyway, and why take a chance on an unknown? As the old saying goes, nobody ever got fired for buying IBM.

I thought we had a great advantage in our much much lower cost over QuestBack, and I looked with some arrogant disdain at the model of using a consultancy package and sell it for a very high price, something that in my mind just meant that their software was not good or user-friendly enough to be used without the help of a consultant. I failed to realize that a lot of people in position to make purchase decisions in enterprise are highly motivated to make ‘fool-proof’ purchases, i.e. purchases where they minimize the chance of them later being blamed for choosing the wrong product. The price is *not* a strong factor in that decision, because it is a one-off cost (or a once-per-year cost at most). The baked-in consultant from the product’s company, the person you always can call who knows the system and will help, is therefore on the other hand a great value-add *for the purchaser*, even if the users later never call his/her number.

Another aspect where I didn’t do my homework is the simple exercise of setting up a price strategy for your product based on your expenses and your target revenue and profit.

What we did instead was to price the product in a way that we thought was ‘fair’ and would let smaller entities and private people try out the product, but (hopefully) would allow us to earn big bucks as bigger companies signed up for the enterprise edition of the software.

There is nothing wrong with looking at price in this light, but it must not be how you ultimately decide the pricing. Instead, you need a clear plan, with projections for sales volume, revenue and profit based on certain assumptions about the market.

And then, as you probably will experience, those projections turn out to be wrong. That is not a fail! You will simply have to try something different, make a new plan and new projections. If you never made projections in the first place, you can not see that you are heading down the wrong road. And if you can’t see that, you can not clearly see that you need to change something.

Reasons reasons reasons…

There were some more, shall we say, supportive failures. Factors that in themselves might not be deal breakers but contributing factors.

One thing that is more obvious now is that we should have built a more social experience around the free tier of the webapp. Our free tier meant that you could use the web app in its basic incarnation for up to 100 answers (1 participant = 1 answer). This is enough for many people, and allows a person to use the web app to run real surveys that can produce valuable results. Think seminar participant feedback, for instance.

There is a germ of a social network effect in there, because one person, the survey producer, sends out invitations to many people. If we could only capture one or two of these people to try and use Beetrieve, to then again send out invitations to their own survey, and we could capture one or two of those participants again…

For that to happen, we would have had to be really smart about it, and we weren’t. Survey production tools aren’t really eminently shareable in themselves (because, let’s face it, they are boring), so we would have to build in a good, social reason for people to share.

We did eventually start to think about a loyalty program where you could earn points which could unlock more answers on your account if you managed to get affiliate traffic. But it was too little too late and it wouldn’t have answered the central question about why it would feel good to share Beetrieve well enough anyway.

The lesson here is that your product should have a good built-in reason for people to want to share it with their friends, and the best reason is if you can build a product that gets an immediate value boost by the very act of sharing it, both for the sharer and the sharee.

 


 

Let’s recap the entrepreneurial lessons gleaned:

1. Don’t focus all your energy on that one aspect of your business that you like the most. As a founder, you need to nurture all sides of your start-up: Product, marketing, sales, accounting….

2. Clearly define and focus on the market segment you want to capture. Learn who your competitors are, respect them, learn what they do and why they do what they do. Then try to outsmart them.

3. Understand the market you are entering. How does it work? What are the driving forces? Where are the bottlenecks, and why are they there? What are the players and what are their motives? There are endless questions to be answered but the more you understand about it the better equipped you will be to succeed.

4. Set up a product pricing strategy based on your costs, knowledge about the market, and projections about what revenue and profit you except over time. Then be ready to reevaluate the same and pivot as you learn more about what you are doing.

5. Make your product such that it has built-in share-ability, making people want to show it and share it with their friends and on social media. Do not think that this will happen just because it is an awesome product. That’s not why people share, they share things for perceived enhanced social status, their own benefit (monetary or otherwise), or for reasons of solidarity. Tap into that.

Fail fast

One bonus piece of advice. You might have heard it before: As an entrepreneur, fail early and fail fast. Very true, take it to heart! But the addendum, without which that piece of advice is useless, if of course, pivot equally fast after a fail.

Get up, turn around and try a different approach. A different market segment. A different price strategy. A different product. Just try again, but for goodness sake, change something.

Good luck!

Leave a Reply

Your email address will not be published. Required fields are marked *