I admit, I’ve been overly fascinated the past few years about all the hyped web startups, and I’ve read countless articles on the don’ts and don’ts (do’s are very rare) of the entreprenuerial track (read “the hard way”). I was beginning to wonder if it was all for naught, and then, out of nowhere, I was asked to help develop a (currently in stealth-mode) startup platform. We launched our alpha version last week; how fridiculous (freaking ridiculous) is that?
Far less glamorous than I may have led you to believe so far, startups grow more from one’s failures than one’s pre-existing knowledge. It’s one thing to read the latest 37signals mantra, and quite another to create something that won’t pee its own pants when pressured. In liu of the all-encompassing list of lessons learned (which will come later), here are a few bite-sized chunks to whet your appetite in the meantime:
1.) Assume it will all change
Never spend more time than necessary to make something perfect. It will NOT be worth it. Ever. Things change. Roll with it. Fast, flexible, and far-from-finished is light-years ahead of perfect. Perfect can’t handle the list of modifications it gets two minutes after it completed the feature. Perfect gets frustrated and wastes time thinking about how perfect it was. Perfect defies the very point of it being a startup (let alone an alpha release). I think you get the point.
2.) Too much flexibility makes things too hard
If you’ve designed your app to be so flexible that it could mutate from an online service to a social network overnight, you’ve likely screwed something up. Make educated assumptions about your approach; you need a consistent foundation. At least that way you could do a mass find/replace when you decide to change. Decide the approach that makes your life easiest (and with healthy regard for both the present and the future, no less) and setup functions and objects that corner yourself into maintaining that approach. My motto is this: if it’s so flexible that it could do anything, then it does nothing now.
3.) Be straightforward, not clever
Sure this applies at many levels, but I am specifically referring to coding practices. Sure you might find some cute way of shortening a function to 10 lines of code, but you still have to remember how it works later. Not only that, but you provide better value to the product if someone else can easily decipher how it works. Forget job security; when you’re done, you’ll want to stay done.
Well, now I have list of bugs to iron out, and the caching mechanism could use some optimizations. This is fun; I wouldn’t trade it for anything.