Archive for November, 2011

When Funding Goes Bad

A well funded business doesn’t have to focus on profits, or in some cases even revenue. I believe this is a risk, which can damage the potential of a business and prevent it from learning important lessons early on that could cost it huge amounts of money down the line.

Many startups are rightly encouraged to launch early and then iterate like crazy, constantly listening to their customer feedback, honing their product into something ready for sale. This makes sense for bootstrapped businesses, and often it’s the only way they can operate since they’ve no choice but to chase revenue in order to keep the business going.

You’d think that a well funded business would follow the same approach. Sure, they don’t need the revenue quite as early, but the value they’d get from the customer feedback could save them millions of dollars later on.

Case Study: Segway Inc.

Take the case of the Segway PT, the innovative ‘personal transporter’. This is a great example of how a well funded startup can get it wrong by not testing their product in the wild first. The company was founded in 1999 by an inventor named Dean Kamen. Born in New York, Dean’s history is an interesting one. He’s a great example of the modern day inventor and the more I read about him the more impressed I am with what he’s achieved. But all his great inventive abilities and personal success couldn’t help his new plucky startup get the basics right.

The first Segway was unveiled in December 2001 to much fanfare, and was announced as a revolution in personal transportation. The company had announced an annual sales target of 40,000 units in it’s first year and expected to clear 100,000 in the subsequent 13 months. But things did not go according to plan. In fact, things went so bad that between 2001-2007 there was less than 30,000 units sold in total – not exactly a revolution.

Nowadays Segway are extremely coy about their financials and many believe that they are still not profitable. To date, Segway have received €151M in funding so it’ll take a while for them to pay that back at the rate they’re growing now.

The problem with the Segway, as most people know, is that you look like an idiot when you’re on one. There is a zero coolness factor for having one and you can probably expect to be slagged by your friends if they see you using one. As a result, hardly anyone buys them.

This could have been easily avoided, but with their well funded manufacturing plant in New Hampshire, Segway steamed on ahead producing thousands of units without getting proper feedback from their customers first. It’s my view that if Segway was a bootstrapped company and not a well funded one, they would have been forced to start selling earlier, and getting feedback from their customers. They would have realised that yes, the Segway was not cool, and making a vehicle that people actually looked good while they used it was as important as all the other benefits.

But this didn’t happen. They had their heads buried in the sand, or in this case, in the lab. Their funding was the catalyst for their mistakes. Without it, they would have been forced to launch earlier, and they would have realised their design flaws well before they’d spent millions in production.

Segway are still operating today, but they’ve moved into different markets and mostly focus on corporate sales. They might get it right in the end, but not before the’ve wasted millions of dollars on poor decisions that could have been prevented by getting early feedback and iterating like crazy.

I witnessed the benefits of this approach first hand on thedebs.ie this month. We’re a bootstrapped startup that’s now well and truly trading. We’re learning new things from our customers everyday and we’re constantly changing our plans, our strategy, our revenue streams and our business models as a result.

A bootstrapped startup is a crazy roller coaster ride, but because we have no other choice then for it to be profitable from day one, we’re open to making those changes as soon as they need to happen. That’s an important lesson for me, and I’m sure for everyone else out there trying to do something new.

If you’ve got a great story about launching early and iterating quickly, why not drop a comment below? The more people that learn this lesson the better.

UPDATE: It seems that in 2009, Paul Graham of Y Combinator fame wrote a very similar post to this one.

Comments Closed

The Web App Economy

Killiney at Dusk

They say that when everyone is panning for gold that you should sell pans.

It’s a clever statement and fits well with the spirit of an entrepreneur. I’ve heard it used time and again in the web industry as an argument for building software designed for other software developers. Over the last few years as I’ve become more experienced in the business of web apps I have formed a view on this which I’d like to share.

The argument for selling to other software developers

Positioning your business to sell to other software developers can be very attractive. There are a lot of reasons why you or I would see that as an easy market to target. Here’s a quick list of some of the benefits of designing software for other developers like myself:

  • we’re online all the time, so it’s easy to market and advertise to us;
  • there’s a strong community of developers, it’s easy to find us;
  • we value good software and are willing to pay for it if it makes our life easier in some way;
  • we understand the business model. We ‘get’ why you’re charging us;
  • we’re not scared to buy online, it’s second nature to us;
  • we also tend to be noisy. If we find something we like, we share it with other people;
  • and we’re not afraid to try new things.

All things considered, it’s pretty easy to see why more and more developers are choosing to build tools for other developers. Here are some great examples of software especially targetted to other web developers:

  1. Basecamp
  2. Freshbooks
  3. Campaign Monitor
  4. Postmark
  5. Intercom
  6. Stripe
  7. Twilio
  8. Wufoo
  9. Beanstalk
  10. Springloops

There are new ones popping up everyday. Just keep and eye on Read Write Web or Smashing Magazine and you’ll see what I mean.

It’s hard to argue against what companies like this are doing. There are some really really good reasons why an entrepreneur would go after web developers as a target market. But I’m going to give it a shot anyway, and tell you why I believe we, the web developers and entrepreneurs, should be looking beyond our own community to build a web business.

The argument against selling to other web developers

If all web developers only sold to other web developers then that micro economy would be a zero sum game.

Just for a moment, let’s use our imagination and try to think of the web community as a country, it’s population made up entirely of web developers and the trading that goes on between those web developers are that country’s local economy. Are you with me so far? Okay good. Now try to think of everyone else (i.e. the non-developer folk) as the populations that make up the other countries in the world.

Okay, now let’s try and think of this argument in terms of a local and an international economy. By trading amongst each other we are simply pushing money around between us. Web developers selling to other web developers.  We’re not helping to bring new money into the local economy.

Let’s keep the analogy going for a little longer and focus now on the international economy. Web developers that sell to to the non technical folk, the people that make up the other countries, are helping to bring in new money. They’re expanding into new markets and growing beyond their local community. They’re figuring out how to bring new wealth into the economy.

The web developers who simply sell to other web developers are really just passing on the responsibility to someone else to figure out how to bring in new money to the web app economy.

Selling outside of the web development community has a number of very real benefits:

  • it’s a huge market. Millions of different niches, billions of potential customers;
  • there’s less competition. When everyone’s selling to developers, you could be selling to everyone else;
  • there are tons real of problems that need solving;
  • opportunities for new business ideas are everywhere.
  • there’s less of a risk you’ll be providing a solution to a problem that doesn’t exist;

All that being said, there are some developers and companies who have decided to step outside the community and are selling into new industries. Here are some great examples of software targetted to people who are not web developers:

  1. Diary Monitor – built for Dentists & Doctors
  2. Decisions for Heroes – built for Search and Rescue Teams
  3. Salon Monster – built for Beauty Salons
  4. Snapizzi – built for Professional Photographers
  5. Fishpond – built for the Film Industry

Just in case you think I’m against writing apps for other developers, I’m not, I’m simply saying there are massive opportunities outside of our own community. In fact I believe that as an industry we’ve spent the last 10 years honing our skills, learning how to build great software and laying the groundwork for us to go out beyond our comfort zones and to start solving bigger problems. With the foundations laid, and our understanding of web apps and online software a little more mature, I think we should start to look beyond our backyard, to start ‘trading internationally’ and start solving problems for other industries, and not just our own.

Photo credit: Killiney Bay at dusk. November 6th 16:20. Taken with an iPhone 4.

Code Igniter and Smarty Template Engine

Earlier today I decided to spend some time looking at new ways to improve Code Igniter’s template code. I’ve been using Code Igniter for about a year now and I’ve always been a little frustrated with how it’s template code can get a little out of hand. Sure, PHP has a shorthand syntax but it can still get a little messy without a lot of self discipline. Now I could blame myself and my sometimes undisciplined coding habits, but I’d rather blame my tools and look for a better way, which is why we aren’t all still coding in the 8086 assembly language.

So since then, I’ve been on the constant lookout for better ways to structure the template code. I’ve been coding professionally now for a good 10 years and I’ve still not seen a better way to seperate out PHP code from frontend code than by using Smarty.

I started using Smarty in 2005. It’s the most popular PHP template engine and sports it’s own template language. If you’re a PHP developer and you’ve never checked it out, you should take a look. You’ll have to go through the hassle of learning it’s own templating language, but once you’ve done it, you’ll see how much simpler your frontend code can be. In fact, I’ve never managed to find a better way to write it, which is why I started looking for ways to improve Code Igniter’s frontend code, and you’ll never guess what I found. It turns out that I can have my cake and eat it, I can use Smarty with Code Igniter!

I stumbled upon this excellent tutorial, written by coolphptools.com where it shows step by step exactly how you can get the two of them working together. So, I followed it, and made some small improvements along the way.

I won’t repeat what the tutorial covers, you can check it out if you want to go through the steps yourself, but if you just want to try it out, then you can download my working copy of Code Igniter and Smarty.

I used Code Igniter version. 2.0.3 and Smarty Template Engine version 3.1.4 along with the bridging code provided on coolphptools.com. In my environment I used PHP version 5.3.5 running on Apache 2.2.17. It’s also worth noting that  Smarty v.3 is not backwards compatible with PHP 4.x so if you haven’t updated to PHP 5.x by now, you should.

I made two slight amendments to the steps outlined in the tutorial.

Template Code Delimiters

I changed the left and right template code delimiters from the standard curly brackets to a combination of tildes and square brackets. If you write a lot of Javascript and embed it in the template files then the default code delimiters in Smarty can cause a few issues…

So with my new change {smarty_variable} becomes [~smarty_variable~].

It’s a little more verbose, but gets around having to use {literal} tags everytime you need to add Javascript in your .tpl files.

Error Reporting Level

By default in Smarty 3, template error level reporting is not used. Instead Smarty uses the global error reporting defined by PHP. As many Smarty templates use code such as:

<snippet>
[~ if $message ~] Please complete the form. [~ /if ~]
</snippet>

… then in times when $message is not defined and PHP is set to throw an error on a Notice then this
code will display an error. As this code is very common, particularly in legacy .tpl files, I amended
the Smarty.php file again to not throw notices on errors in the Smarty templates.

If you haven’t tried out this combination, then this should help you get started easily. It’s a great combination that combines the power and structure of Code Igniter with the simplicity of Smarty in the view.

Download the Code Igniter and Smarty Package.

UPDATE: I’ve put the code up on Github: https://github.com/iarfhlaith/Code-Igniter-and-Smarty