Technology and Expediency
“Everything should be made as simple as possible, but not simpler.”
– Maybe Albert Einstein
One can start a technology company by spending time working on a slick pitch and pounding the investors with pavement (that’s roughly how the saying goes, isn’t it? Doesn’t sound quite right) until one is given enough money to put a team together and finally sit down and start making a product. Or — at least in the web industry — one can start making the product first, and then go after money when one has something real to show off — both for a visceral demonstration of how you’re going to change the world, but also (and perhaps more significantly) because you’ll be that much closer to revenue, have that much less risk, and hence be that much more fundable. As a bonus, you have a nice built-in Plan B: even without significant funding, you can conceivably launch slow (as long as you can beg and borrow just enough cash to cover operations in the short term), start refining your product, make connections with users, and even start making revenue.
But there’s also a pretty clear downside. If you have a good idea, a viable opportunity with the right timing and a decent market, you can be bloody certain you aren’t the only one with that idea. That means if you don’t get to the starting line before your competitors, you’ll lose first-mover advantage — which isn’t everything, certainly, but is certainly better than a poke in the eye. And for whatever method B’s strengths, the necessarily small and often part-time team means that time-to-market isn’t (usually) one of them (though don’t forget that it does take time in method A to woo investors — time not spent on making a product).
Jectiv is taking the latter path, for better or worse. But this means that time and effort are precious, and the goal is to put together a prototype with the absolutely lowest effort feasible on the shortest timeline possible.
It helps, here, if the founder is also a software developer.
So you gotta pick technologies based on how efficiently they’ll let you build a product. Agile development is the name of the game, The Simplest Thing That Can Possibly Work is your mantra. Perfect is the enemy of good enough, yada yada. This can be a difficult process for perfectionist engineers who habitually do everything in their power to make things three times sturdier and more flexible than they strictly need to be.
But then, this is complicated further by the fact that, unless dollars fall from the heavens from gushing angel investors and VCs as soon as they’re given the faintest hint of a demo, chances are what you build now is the same code that you’re going to launch your beta with, and probably your public launch, and the first few years after that… so you’re not really building a prototype after all, you’re building The Product. Just the smallest, simplest, most important subset of that product you can identify. But you’ve gotta build that subset well enough that it won’t hold you back once you do make it. It’s bad enough to shoot yourself in the foot, but doing so just before running a marathon is a Bad Idea.
So: architecture is important. Just don’t furnish any of the rooms you won’t be living in the first day.
We’ve learned some lessons already while going down this road. Sometimes shortcuts aren’t as short as you’d like (ever notice there’s no reasonable Ruby Servlet-level solution under Apache if you’re not using Rails? Ever notice JAXB and RelaxNG simply will not work together?). Sometimes the most expedient technology is simply the one you know best.
We’ll keep trying to do this thing fast, but damned if we’re not going to do it well at the same time.