Working practices

Building to last and building to survive

I used to think it important to take a build-to-last approach to their core software. Now I’m more pragmatic. If you only have finite resources then build-to-survive may be the best option.

The change in thinking has come about through working with a few startups, and there the dynamics can be very different to what many of us are used to. Some of the key factors can be: you have no money supply beyond a few weeks; none of your founders are developers, so you actually have to pay your developers real money now (not deferred payments, not options, not equity — money now); and you have no certainty that you even have a viable business.

In the end, if you have only, say, six weeks’ money then it doesn’t matter what wonders you’ll be able to do in seven weeks, because you can’t last that long.

Undoubtedly there are downsides to this. In particular, you’re almost certainly building a business on a poor foundation and — as I’ve said before — there’s nothing so permanent as temporary. But it is possible to escape that if you look on it as a bootstrapping process: v1 gets us enough money to replace it entirely after three months with v2, which gets us enough money to replace it entirely after six months with v3 which may last three years before before the last line of that code is replaced.

But build-to-survive is an exception to the rule. As soon as you have a development team which you can call your own then quick and dirty is dangerous, especially in a small company, because both the benefit of quick and the cost of dirty are felt by the same people.

Advertisements

Discussion

2 thoughts on “Building to last and building to survive

  1. Interesting post, and follows a lot of my own post Guardian experiences. I wonder if “build to migrate” might start to make sense as a mantra for start-ups.

    Posted by Tom Marsh | 29 February 2012, 2:09 pm
  2. Hi Tom. It’s very interesting that you highlight the phrasing, because that often determines whether an idea catches on or not. “Build to migrate” does sound like it has more clarity about what to do with the software. Depending what stage you’re at you might have different matras: build to validate; build to win funding; build to float(!); build to last…

    Posted by Nik | 29 February 2012, 2:21 pm