Managing Technology Risks close

David Hart
In Musings, Codegent College, Apps
4th April 2014
Managing Technology Risks

Entrepreneurs are attracted to creating a digital business for a number of reasons: the chance to ‘disrupt’ the existing status quo; the ability to sell direct; a belief that scalability is easier; the possibility of reduced costs; quicker exits; flexible working patterns.... And we get ideas for digital tech products and businesses from every direction. But the one thing that surprises me again and again is how the platform that is in effect, the business, is often consigned to the category of a ‘commodity’ that has to be bought. It’s simply one of the hurdles, in a long line of hurdles.

The trouble is, if you just give it to a guy who knows a guy who has built his own app and doesn’t cost the earth, there is a very high chance you’re going to make a mistake. Just because you know your industry, you got an MBA and you’ve raised seed investment, doesn’t mean to say you know how to create a digital product. And even a competent coder, won’t necessarily be thinking of your longer-term commercial objectives.

We’ve put together a list of 9 of the main technology risks entrepreneurs don’t consider and ways in which you might try and mitigate for them.


Your investors are backing you to create a product that nobody in your sector has produced. It’s a way of sharing best practice across your industry and to start with, it will allow people to connect, message and share documentation. Yeah, that’s easy enough. So you hire some guys and they build it for you. $100k of your $1m gone and 6 months in and the investors seem pleased. The product appears to do what it’s supposed to.

But it doesn’t scale. Any more than 100 concurrent users and it falls over. Also, it hasn’t been built with APIs in mind. So, whilst it’s great as a web app, your plan to spin it out as a mobile app will just have to wait.

12 months later and 80% of the way through your funding, you realise that, although you’ve convinced people to use the product, perhaps with the promise of future functionality, the current set-up doesn’t cut it and you need to start again. After the $100k initial investment, you spent another $150k sellotaping functionality on and papering over the cracks. Now you need at least $250k to start from scratch with an architecture based on the actual needs of the platform, rather than the vanity needs at the beginning. You’ve just wasted a load of your time and your investors’ money.

Mitigation steps

We’re all for MVP (Minimum Viable Product), but an MVP that becomes useless after a year is probably a Prototype. If all you set out to do was create a proof of concept, then that’s fine (although I’d argue you should be able to do that in weeks rather than months). But, an MVP should be built to allow for scalability and future iterations. Consider everything you think this product might be (but don’t try and build it all at once). And ALWAYS build with APIs in mind.


Connected to the above. When you started, you were thinking that you would need to capture your users’ names and email addresses. As time has gone on, you realise that the real value in your product is not in the functionality, but in the data: the way people in your industry interact; the information they share; how they move from job to job. But you didn’t think about that when you started. How is the data stored? What is collected? How structured is it? How easily is it to analyse?

Someone has ploughed a load of someone’s cash into the wrong thing. Because, although they were experts in their industry sector, they were absolute novices when it came to digital product innovation. They hadn’t known what questions to ask. We recently saved someone from going down this exact route: probably creating way more value for their investors who probably will never know how easily it could have gone a different way.

Mitigation steps

You need to really think about the future value of your product. It may be that you need someone who’s done this before to work with you and make sure you haven’t missed anything. Then it’s about understanding how to structure your data so that some hitherto unforeseen opportunity isn’t lost because your information is missing or too rigid. It’s not easy, but then that’s why most people mess it up.


You’ve got this great idea for a bit of wearable technology. It’s genuinely unique and solves a real problem. But it requires people to invest in and set-up some hardware. It’s not impossible, there are lots of other people out there with successful products that also require hardware. But in your business plan, you needed to have 5,000 active users within 6 months of launch. Trouble is, after 2 months, you've only managed 70 active users and because of some initial teething problems with the hardware, some of them are fairly irregular users and the rest require almost daily technical support.

This is a classic mistaken assumption: our product works, people need this product, therefore people will use our product. Not necessarily so. There is a lot of validation that needs to be done, and if your business plan means that you fail if you don’t get acceptance straight away, then even the most promising product might be doomed from the start.

Mitigation steps

Validating the market in advance will help give you a sense of how eager people might be to buy into the technology. Remember that there is a dual task of both promoting your product AND promoting your new ‘sector’. It will probably take longer and cost more than you think, so don’t force your business to be reliant on ridiculously fast take-up.


A bit like technical acceptance, the very fact that what you’re doing is ‘disruptive’ means that you are asking people to change their behaviour. Just because your product is better than the alternative, doesn’t mean that people will want to change their behaviour at the same rate that your business plan dictates.

Your product may mean you never buy toothbrushes in the same way again, and neither will some other people, but it might be a while before the rest of the world cares enough to disrupt this particular part of their lives. And whilst there are ways to validate and prepare for this, too many people seem to place their entire trust (and money) on their gut feeling.

Mitigation steps

Exactly the same as with technical acceptance: changing behaviour takes longer than you think, even if everyone you talk to says that what you’re doing is a great idea. Believe me, we’ve been there with our property business, Tepilo: one of our biggest challenges is that most people still don’t know that Online Estate Agency is a ‘thing’. The business is now growing fast (currently 50% a month) but this hasn’t happened overnight and has needed a lot of effort in the background to change perceptions.


Everyone is a designer. You’re a bright person, a successful career so far, now why don’t you have a stab at designing an app, too? After all, how hard can it be?

This particular risk could be a blog post in itself. But if there is one thing guaranteed to kill a good product idea stone dead, it is poor execution. So why do people try and do this themselves or use people so unqualified for the job? The reason comes back again to this notion of the actual design and build of the product being a commodity. Have you used an app before? Can you use Photoshop or know someone who can ? Great – that’s the whole User Experience that your entire business is relying on sorted, then.

And even if the UI doesn’t end up being an ugly pig with no consideration for the platform it's sat on, we know that tiny changes to things such as button size, syntax, overlays, reveals, content surfacing, form-fields etc, can have a significant impact on discoverability, conversion and retention rates. Miss this and you risk sizeable chunks of potential revenues in the future.

Mitigation steps

Seriously. It’s too important not to do it right. You need to find someone with a track record of designing products who understands, not only User Experience, but also the nuances of the devices and platforms they are designing for. Radioplayer, for example, understands the different Use Cases for a tablet and a mobile phone (because they’ve researched it). They also understand that Android has a different feel to it than iOS and different design conventions. It’s why the work we did for them consistently gets rated higher than any other radio app in the UK.


This is a tough one. Let’s take the industry expert, MBA person again. They’ve raised $1m because their investors believe they are a good bet. But, although the technical platform is a central part of this business, does anyone in the management team know how to deliver the product? This comes back to the commodity idea again. Just because you know some dude in Poland who makes apps, it doesn’t mean that your product is going to be right. How do you know what you're actually buying? How do you assess what you’ve got and how it’s been built? Getting this wrong could mean that you burn through your cash and don’t even get a prototype to market. I’ve seen this a lot: people exasperated by their (probably cheap) developer being unable to deliver anything approaching a Minimum Viable Product. They always start with asking whether we can finish off what someone else started and always end up by having to start again. I’ve never seen an exception to this.

Mitigation steps

The only way really to mitigate against this is to either seek reassurance by looking at the other similar product work they have delivered before, or get someone who really knows what they’re doing to advise and assess before you make a decision.


What are the technical building blocks you’re using? What programming language, framework and other services do you have? Use something that is at the end of its lifecycle and you run the risk of it not being supported in the future: developers may be unwilling to work on it. Use something that is so cutting edge or niche that there just aren’t the developers out there to work on it may see you struggling to find affordable resources to maintain the platform.

Mitigation steps

Get a few opinions on the technology stack being proposed. See what the consensus is. Maybe even pick up the phone and talk to a recruitment agency or two about the current rates for developers with the skills required: they’ll soon tell you if a particular language is easy to recruit against.


There is a growing phenomenon: the ‘aqui-hire’. Companies paying to buy an agency or a product, not because they’re interested in the revenues, but because they want to buy the whole team. For example, Google bought apps company, Milk, then killed off all of its products and set the team to work on Google+.

Why? Because teams that have worked together for a while, know and trust each other and can work efficiently. What’s more, they will have a library of shared code that will allow them to ramp up quickly.

Try going out and hiring a tech team when you don’t really know what you’re doing. You may be lucky. Chances are it won’t be plain sailing. And you might not even know that the team isn’t working for several months. Once again, you’re $100,000s down and your business is set back a year.

Mitigation steps

Unless you are, or have hired someone who is, a superstar developer with years of experience and access to a network of trusted and available staff, there are only two ways really to mitigate against this: 1) do an aqui-hire of your own, or at least try and poach a whole team en masse. You will need deep pockets, though; or 2) find a product studio like Codegent, who is geared up for this and has a team of people who have worked together on numerous products, understand how to work efficiently and have a shared reusable code library.


Strictly speaking this is a marketing risk, but so often marketing is considered a nice to have because all the effort has gone into a product that cannot fail to be an overnight success. People think that they can emulate Rovio who invested €100,000 in a game called Angry Birds and within 12 months got a return of €50m.

The trouble with that theory is the guys behind Angry Birds had produced 51 titles before they created their blockbuster. And when you also realise that Rovio, in 2009, was close to bankruptcy, the notion that Angry Birds was an overnight success, starts to fade a little. Without a solid understanding of how you are going to reach your market and a realistic budget to do so, your world-class product could well remain the internet’s best-kept secret.

Mitigation steps

Marketing isn’t optional. One of our first questions when people approach us about product development is ‘what is your marketing plan?’ Sadly, too many people mutter something about social or viral (read: we don’t have a marketing budget) and assume that the strength of their idea will be sufficient.

Creating a business isn’t easy. Creating one around a digital product isn’t easy, either. And while investors and entrepreneurs can be adept at negotiating risks around law, finance, competition, market and people, the risks surrounding technology often feel like a footnote. So long as you can find a developer and negotiate a good price, that’s the limit of your technology risk. Don’t let all your great ideas and hard work go to pot because you didn’t properly consider the technical risks associated with digital product innovation.