7 Technical Risks of IT Startups
Implementing a startup project, regardless of its nature, is associated with a number of risks that need to be taken into consideration. When a project is implemented properly, the risk can be efficiently curbed by the startup founders during the different stages of the project lifecycle.
Statistically, more than 20% of all the risks technology projects are derailed by are associated with a startup’s technical implementation, and not the erroneous selection of the market niche, or how innovative their product or service offering is.
In other words, this means that even the brightest business idea has a good chance of getting driven into the ground by what is totally beyond the control of even the most influential and astute of all angel investors, unless they happen to be a qualified technologist with a wealth of time to share.
Many investors would, most probably, take issue by claiming that most startups have their CTOs, and that bringing one into play as a new hire should solve the problem for those that don’t. However, they would all be poised for an answer when asked about why 20% of startups still fail for reasons none other than technical or technology-related.
In any event, most of the risks below are all too well-known, and just need to be dealt with in a proper manner by you as an investor. After all, if you need something done well, do it yourself. Or, get ahold of the right partner.
Risk 1: The Startup Team Does Not Include a High-level Technical Expert
The one gross mistake that is rife and rampant with startups is not having a technologist on board who fits the caliber of the project. It is imperative for an investor to check whether a startup team includes one. Moreover, the problem is diverse and complex: even if the team you have in tow does have someone they call their CTO, how can you as an investor be sure it’s the right person for your investment to pan out?
In those cases, when the original idea did not belong to a technical person, entrepreneurs tend to invite their friends or associates. Frequently, they simply have no means of attracting someone qualified enough. On the flip side, employing someone qualified enough for the funds that you put into the startup does not really guarantee you anything: a hired person may not be all too keen on the business idea at hand, and, in any event, they still have no responsibility, formal or moral, for the outcome of the project’s implementation.
As far as VCFs are concerned, even for those of them that have a CTO to supervise the technical implementation of their startup projects, it would be more expedient to enlist the regular support of a corporate partner that has the diverse resources and relevant experience to control the multi-faceted implementation process.
Risk 2: Scoping the Application Incorrectly
Another common risk is overly expanding the functionality of the software application that underlies an IT startup. Gilding the lily in search of perfection is what that has uprooted many a startup through overextended time-to-market and overinflated functionality that had nothing to do with the ROI. The mistake is so common and so potentially devastating that one should almost expect it to be made by the startup they are investing in. What normally happens (and it is only natural to happen, to tell you the truth), the technical folks on the startup team either get influenced by the entrepreneur folks, or they are just not very interested in whatever lies outside the technical realm. Often, the price tag on project development is way too much to ensure the product’s further efficient marketing.
An angel investor, or VCF, that doesn’t want to bankroll any surplus functionality, should rely on knowledgeable IT consultants with sufficient BA experience as auditors for the project. It would also be worth considering going offshore with a reliable service provider.
Risk 3: Excessive Operational Costs
As many start-uppers think that building a good product, finding the right market niche, and picking the right moment to surface is all that will do the trick, some of them are in for a very bitter disappointment. The delivered product may well turn out to be too dear to operate, for example, because of the high data and processing costs, poor availability of third-party hardware or software, or high usage costs associated with the latter.
A case in point would be the virtual network operator Samba Mobile that provided free data through clickable ads and went out of business because they “had to take the difficult decision to close, primarily due to high and increasing – and therefore unsustainable – data costs”. Finally being in possession of a fully functional product the company had to admit that: “the current model of offering a meaningful value exchange of mobile broadband unsustainable.”
Sedna Wireless, a startup whose flagship product is CallGraph, an application for the recording of Skype conversations, indicated “the hardware ecosystem in India” as one of the reasons for their inability to carry on with their business plans. Actually, it is quite possible to predict and rule out scenarios like these ones, as the reason for them arising is the poor system requirements’ definition.
For an angel investor or VCF, the recipe would incidentally be consulting from a full-cycle software provider with relevant development experience in the corresponding business domain.
Risk 4: Selection of the Wrong Technology
Selecting the wrong technology for the implementation of a startup IT project is rather a common risk, insidious enough for the investor to be left with a semi-functional trinket one can neither sell, nor capitalize on due to its poor integration ability, scalability, and competitiveness.
While you, as the investor, are interested in determining objectively the technologies that should best be used, a hired CTO, or the start-up founder who plays the role of the technical guy, is more likely to be biased in favor of his or her own technology skills and preferences.
Investor reliance on a well-seasoned custom software vendor with a broad technology stack, or on an experienced IT consulting company, will become the best solution to secure the investment against these kinds of risks.
Risk 5: Relevance of the Suggested Technology Idea
The idea that you are offered to invest in, may actually happen to be so brilliant that it may put you many years ahead of the pack, but what will you do there alone?
While the market may not yet be ready for some otherwise brilliant ideas, you should always check how relevant the technical format of your start-up’s output can be to the currently existing market. The mobile startup Inq Mobile (http://www.inqmobile.com), well-known for creating one of the first Facebook phones and providing algorithms to receive data from Facebook and Twitter, was forced to shut down after five years because of the failure to cope with problems such as mis-categorized or irrelevant content, and the overall inability to provide content that would look editorially processed.
Risk 6: Project Development Risks
Software development is a multifaceted and complex process that requires quite a bit of specialized skill and experience, and the successful implementation of an IT project hinges upon a plethora of factors. Due to this, the process can hardly ever be efficiently monitored by an angel investor. The major points that require attention may include:
• Prioritizing the features and bugs.
• Testing of releases and updates.
• The approach to creating and reviewing technical designs.
• Task estimations.
• Observance of deadlines.
• Effectiveness of the methodology and bug-tracking system.
If you happen to be an angel investor with in-depth technical expertise, it is a lucky fluke you shouldn’t keep banking on too much: you will also need a lot of time, and at least some knowledge of the corresponding business domain.
VCFs are in a better position to control the implementation of their startup projects if they have a qualified CTO and other technical experts of their own. However, it may still be hard for a VCF to reliably monitor and control any significant number of concurrent projects, all the more so if the projects being implemented are strewn across a wide range of business domains.
Risk 7: QA Risks
By comparison, this category of risks may seem quite insignificant to a non-technical person. In consequence, this, seemingly, not the most dangerous peril, has been successfully plaguing a number of IT start-ups, and helping them go belly up as part of the poorly organized software development process.
Not so long ago, the startup community was abuzz about Flud (http://www.theflud.com), a budding mobile startup that raised funds in excess of USD 2 million in seed financing. When asked about the reasons for shutting the company down after 3 years of development in July, 2014, Flud’s CEO said the following, “We actually did not check the initial item enough. The group pulled the trigger on its initial launches without a considerable beta period and without spending a great deal of time running QA, circumstance screening, task-based screening and the like. When v1.0 introduced, problems and bugs swiftly started raising their head (as they always do), making for delays and laggy user experiences aplenty.”
As an investor, one should bear in mind, that although Quality Assurance is something a CTO should overall be familiar with, it is still a separate area of software engineering that uses many specific techniques and methodologies. Your software should preferably be tested by a corporate partner with a well-tuned QA process in place, or by a specialized QA provider.
Otherwise, as a last resort, make sure the project team of your start-up includes at least one QA engineer. Making sure their startup investments are making progress to generate an ROI instead of setting their owners back for just another fortune is a task challenging enough even for those angel investors, or venture capitalists, who have internal technical resources, and virtually impossible for those who don’t.
However, a partnership with a well-established software development vendor is, seemingly, the most optimal option to safeguard an IT startup project against the technical risks involved in its implementation, and the best way to increase the share of successful projects in one’s project portfolio.
Sources:
http://mobilephoneadvise.com/why-startups-fail-a-postmortem-for-flud-the-social-newsreader
http://www.cbinsights.com/blog/startup-failure-post-mortem/
