The pitfalls of being a startup

Online startups are on the rise, springing up around the country despite the credit crunch. With ‘Silicon Roundabout’ firmly established in London’s Shoreditch, there’s more support than ever: the new online Dragon’s Den, networks like Smarta and Entrepreneur Country, post-boom micro-funds and virtual incubators such as Betaworks and Reincubate. The startup CIO must operate differently from a typical CIO, and one of his or her first decisions will be around build versus buy. ‘Buy’, or rather outsourcing parts of the platform to an agency or partner, can be very appealing to a startup. ‘Fail to prepare, prepare to fail’ is often applied to outsourcing, but startup CIOs should heed another mantra: ‘fail fast’. Uncertainty abounds in their operating environment and CIOs should aim to make failures apparent rapidly, and before too much money has been spent. CIOs should also be wary of Stockholm Syndrome, where they find themselves starting to defend inadequate partners from their own businesses. Outsourcing the right way requires experience, and all the more so for low-budget, time-critical projects. Typical outsourcing best practices are not well suited to startups, and most of the agencies within reach of a startup are more used to working with established businesses. With untested business models, few staff and little time, how can startups create strong, trusting long-term relationships with outsourced partners reliant on their revenue? Success with an initial business plan is rare, and with many pre-revenue companies changing strategies or products three or more times before they get to market, it is sensible not to commission a project’s fixed scope in entirety from the word go. VCs typically expect a successful exit from 10 per cent of investments, and success on the part of the startup will radically, and often unpredictably, change requirements. Without terms in the contract to change tack, the agency project manager might step back and let the CIO work directly with agency staff. This can break down methodology and muddle specification ownership. Close communication is key, but CIOs should be wary of the risks of their CEO distracting partners with talk of phase two when phase one is still the objective.

Alongside limiting the scope of projects, prescriptive technical specification is important. Agencies may be able to deliver products that are beautifully search optimised, for instance, but may only do so where explicitly specified. Stakeholders should specify platform metrics to avoid costly or inaccurate data-mining processes. Web and user metrics are common, but there are also likely to be operational metrics that will be reported to investors, or which are key to monitor business performance. Outsourced partners may want to work with their metrics rather than those of the CIO, and are often keen to avoid specifying an effective man-month cost. This complicates tendering, and getting partners to report against the startup’s own metrics is an important principle. Day rates of £600 or more are standard for many businesses but they will cripple a startup. Micro-proofing – building prototypes as often as possible – is a sound principle. Prototyping is cheap, helps the business learn more about what it really needs, and can be a good benchmark for quality and cost creep from the supplier. Startup CIOs would be well advised to double any supplier quotes involving more than customisation of an existing platform. Delivery quality management is hard, and there is no substitute for robust due diligence. Vetting potential partners to find which are agile and follow best practice can save some unpleasant surprises later on. CIOs should cast a wary eye over partner methodology at the outset. Outsourcing a project doesn’t mean the CIO can just let partners ‘get on with it’, and an experienced technical person following the build and chasing agencies will be more likely to get results. A remote third party can often be found to support the CIO if the partners are based overseas. To hasten delivery, the partner may customise an off-the-shelf product to address the project, adapting open source or customising a proprietary product. The CIO should decide whether the agency’s choice is objectively the best fit, or if they chose it because it fits their other project work, or is a new technology that they would like to learn. Smaller startups should be wary of CMS platforms being shoehorned into ill-fitting one-size-fits-all solutions. Secure, robust solutions will not be delivered without the right components.

Less experienced CIOs might struggle not to get caught up with low-level technical specifications, losing sight of the business need and investors’ requirements. CIOs may find their CEOs or boards have made assumptions about the technology strategy which are not made explicit, and even the need for developing or retaining technical intellectual property can be unclear. It is important to recognise whether the agency will be developing a product that the customer will own. If not, there may be a perpetual licence or ongoing licensing cost. With a poorly worded contract, we have known some agencies to bill for a full ‘build’ project, only to deliver a ‘perpetual non-transferable licence’. The investors have subsequently fled. CIOs need ask a number of further questions of their partners: if the project is being built for their ownership, is it being built on a proprietary framework? Is the partner offering escrow on the source code of that framework in the event of the agency’s liquidation, and could it realistically be managed if that happened? Is the software being built using servers or software which could introduce additional licensing cost if hosting providers were changed? One of our clients had outsourced work to Pakistan, and while looking at the publicly accessible development servers of their partner during our due diligence, we found we had full access to a variety of highly confidential documentation from their other clients, not to mention a full, unencrypted database backup of a UK retail business’s customers. Serious security failures like this are uncommon, but failure to comply with relevant legislation is surprisingly prevalent. Even if the partner had secured their servers, the fact that they were storing complete sets of user data outside the EU puts them in breach of the Data Protection Act, and their storage of customer billing details breached payment card industry regulation. The customer’s site did not comply with the updated Companies Act. Where CIOs offshore, and manage to secure tantalising sub-£1000 man-months, most partners will not follow their business’s legal and regulatory constraints. Finally, partner contracts should model what would happen when only some of the functionality is delivered, and consideration of what defines a successful implementation is important. An agency may feel that they have delivered 90 per cent of the functionality, whereas the CIO may feel he has only half the tools he needs. Web startups can fail catastrophically with immense technical complexity when poorly managed, and with best practice, methodology and specification being discarded. They can be left with a mess that is far from the expected delivery, with the cost of making good either unclear or beyond budget. Partners may offer to write off invoices in exchange for equity, or a commitment to further work being put their way, but it is a desperate company that signs up to this after a project failure. Being well equipped to engage at an early stage can make a startup CIO. The role is not for the faint-hearted, but with careful planning it can be immensely rewarding and can propel the CIO to new career heights – or early retirement.

About the author:

Aidan Fitzpatrick is an experienced interim CTO and a partner at Reincubate, (www.reincubate.com) a London-based venture incubator