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.