When it's your own money on the line and you're operating without the safety net of a large corporate infrastructure, lessons tend to crystallise rapidly and sometimes painfully. But you also have the freedom to make mistakes and an ability to adjust quickly to circumstances. That is what is often missing from corporate management; decision makers are often a few steps removed from the rubber and the road.
The issues my team and me grappled with daily in bringing imeemy.com to market bear a striking similarity to those in the jobs we left behind. While we always knew our corporate experience would stand us in good stead, the interesting thing is how the takeaways from a tech startup translate so easily back up in the glasshouse.
To provide some context, here's a little bit about the business.
imeemy is a trusted recommendation engine. You can get answers, advice, ratings and recommendations from people you choose and trust, using the channels of your choice. You specifically ask them for their advice, rather than relying upon the altruism of an anonymous network. It's founded upon the simple idea that the first place people always turn to for trusted information is their family and friends. After 25 years in print and online publishing, that rule holds true whatever the industry. That's the critical and compelling difference between imeemy.com and all of the current advice and recommendation sites.
For the incumbents, the principal aim is to build massive scalability by aggregating everyone's experience. Relevancy, honesty and accuracy are casualties since the flaw in the incumbent model is that the ratings and answers are provided by people you don't know, and whose motives you can't possibly ascribe.
In recent months there's been an uptick in stories about ratings fraud. Yelp has taken to naming and shaming, and many sites are attempting to build complex and expensive algorithmic solutions. But in truth, it's an arms race which they will never win because the incentive to cheat is too strong. Your friends, on the other hand, have a powerful incentive to help you and a strong disincentive to mislead you.
So our business mission was precise and defined, and so was the IT execution underpinning it. Like most startups, we had a small team of up to 10 people, only one of whom was working full time on the business. The founders, contractors and occasionally friends with nothing better to do dipped in and out as required.
The capital base was large enough to do most of what we wanted without outside money to complicate matters, but not so large that we could do everything. We needed to design the strategy and a product roadmap, develop a code base and an infrastructure, deploy it successfully and maintain and improve it continuously.
Running a startup is fun, but frankly this started looking a lot like my day job. A year on, with the product finally live and the commercialisation about to begin, the thing that struck me about the whole exercise was that, while in scale it was a quantum of previous IT projects I've overseen, we still kept coming back to the same themes that drive the IT agenda in the big end of town today.
Here are some simple lessons for Big IT from the small end of the street:
When you’re spending your own money, instead of a distant shareholder's, you tend to take every dollar very personally. I kept hearing stories about how cheap offshoring was, so it was easy to be drawn down that path. But the other thing about spending your own money is that you tend to be more risk intolerant about the big things.
The advice we got from everyone who had considered offshoring and ultimately pursued it was to pick three companies right at the start, give each of them a small job and see who does best. The costs for small incremental jobs are so cheap that you don't mind burning a little in mitigation. We are talking three mini projects typically in the order $1000. Ironically, this is easier to do in a start-up than a corporate where CFOs will generally consider this approach a guaranteed waste of at least $2000.
The other big issues beyond cost are communication and project management. One managing director of a smaller niche publisher told me, "It's not who writes the best code but works best with you. After all, when things go wrong you can't pop around to Mumbai or Moscow and knock on the door."
While there are all kinds of great tools that allow you to monitor what the developers overseas are doing for you remotely and in real time, we found that the people we spoke to with the highest satisfaction levels were those who opted for local project management which complemented the overseas development.
Meanwhile, those who let price drive the final outcome and sent everything overseas never seemed quite as happy about the outcome or relaxed about the process. Mostly that's because they may have got burned by bad communication.
Interestingly, the attitude of the VCs we spoke with ranged from caution to outright hostility about offshoring. "There's no second pot of money so get it right first time." Other entrepreneurs made the same point and it was this advice that most resonated.
In the end, we decided to go local for imeemy.com. The site is built in .net, HTML 5 and CSS 3 with a SQL backend — pretty standard fare. The prices provided by the companies we considered all fell into a cost band of about $90 to $150 an hour.
We didn't choose the cheapest. Instead, we chose the company with a track record we could test and which sent the right signals about commercial realities — not just the cost of the project but also an appreciation of what we would need to do to maintain our business after they were out of the picture.
Privacy is a big part of our product and the fact they had a fair bit of financial services experience helped since it meant they appreciated our requirement to build privacy into the product rather than bolt it on later as a compliance exercise.
It didn't all go perfectly — it was an IT project, after all. It took longer than we anticipated (three months longer than the extra two months grace we built into our original assumptions) but we got there in the end.
The best vendors are partners, not suppliers
Our developers provided us some very sage advice early on that proved to be a winner. "Start mobile and work back out to the desktop." That seems obvious now, but in October 2011 it was still a punt, particularly with our initial conception of the product.
Their advice also lead us into a choice around mobility — we opted for responsive Web design rather than a native application since it offered the most ubiquitous audience fastest. For those of you who are unfamiliar with responsive design it's basically the emerging method for Web apps where you design around fluid grids that adjust to the form factor of the customer's device. In simple terms, there's no second (or third) code base.
If you are building websites today and they are not responsive, you're kidding yourself and wasting your company's money. But this is a different question to whether you need a Web app or a native app.