Choosing Your Platform
These days, with the cost of web-based tools dropping rapidly and the huge demand for qualified tech talent, lots of junior developers are jumping into the startup game. When you find one, it’s tempting to cede responsibility to them – after all, they certainly sound like they know a lot about technology, and you’ve got other things to focus on.
One of the first decisions required for a new product or company is what platform to code on. This is far from a simple decision, and one where starry-eyed-coder-meets-shiny-object syndrome can create all sorts of long-term problems. Re-doing one’s codebase for the wrong reasons can kill a company. Here are some questions to ask yourself when the decision arises:
1. Are we picking the platform for the right reasons? Web tools and platforms are improving with regularity, and developers love nothing more than learning a new tool. Platforms like Django promise to make things easier and more powerful, simpler and better – who wouldn’t want to do their next project on the latest environment? Moreover, in the tech community, fashion changes with the wind, and last year’s darling development environment seems hopelessly old-fashioned this year. Ego and testosterone enter into the picture as well – admitting that you’re using PHP at the next geek gathering can be almost embarassing in 2012. Likewise, picking a platform the developer knows well (but no one else does) can be just as bad, if business considerations are ignored. Too often, the most technical person i n the room can sway platform decisions to their own pet preferences and biases almost without realizing it. Here are some things to keep in mind:
2. Does my tech team know it? Most organizations already have a tech team or a designated technical team. When time is of the essence, asking your team to climb the learning curve on a platform as they are designing and building the actual product is unnecessarily complicating the effort. Great technologists with adjacent skillsets can learn a platform quickly, but selecting a platform they already have skill with reduces the learning curve requirement instantly.
3. Are there enough technical people available to support it later? The latest and greatest platform suffers by definition from at least one flaw: there aren’t enough people who know it – and the ones that do are in high demand. The more successful and appealing the platform, the more of an effect this has on available staff. Remember, your developers are in high demand and can be fickle – which means that they can and will leave. Replacing them can be tricky enough without having to worry about duplicating an unusual skillset.
4. Can it scale to meet my needs? Most technologists are trained to gauge the answer to the scale question by whether or not the codebase and physical hosting environment will be able to accommodate high levels of usage. The truth is, however, that in the early days of a product this is almost never the operative definition of the term ‘scale’. In that context ‘scale’ means can it be simple now and complex later. Questions of reusability and modularity are far more relevant. Don’t worry about high volume until you’ve got the product right.
5. Is it flexible enough to support the constant iterations that will be necessary in the early days? This is possibly the most important criterion. Complex, textbook-perfect development environments can often make even the simplest changes arduous. Successful online products change several times per day in the early days, so things like complex version control requirements or finicky compilation can slow you down.
Next: Five Ways Developers Can Kill Your Startup, Part Two: Outsourcing Extortion
