Careers and Entrepreneurship

How to make an app

Have you ever wondered what makes some Apps successful and others not? Do you have an idea for an App but don’t know where to start? This six-part series will give you valuable insights into seeing if your App has got what it takes.

With the help of three successful App founders and our resident App expert - we’ll be investigating and answering some of your questions. Chris O’Hare, Sussex graduate and founder of award-winning technology consultancy Hare Digital, drills down into common mistakes and things to consider at every step of the App development journey.

This limited series will tackle everything from developing your idea, testing it to see if there’s an audience willing to pay for it, to building your prototype and funding your App. Later in this series we’ll also be looking at things you need to consider when building and launching your App, as well as investigating how and when to grow your business.

This podcast series is brought to you by the University of Sussex and is part of the University’s knowledge exchange programmes. This podcast was made in collaboration with the university’s Innovation and Business Partnerships team. 

Latest Episode

Episode 6 - How and when should I grow my business?

The benefits of bootstrapping and growing at the right time. The importance of thinking about the bits of your business that will need to grow, as your App reach grows. Chris O’Hare in discussion Peter Lloyd, the CTO of TRIM-IT, about the founding story of UKs first App powered mobile barber service, securing investment and growing sustainably.

Subscribe now!

Spotify podcasts badge Google podcasts badge Apple podcasts logo

Also available on Deezer, Stitcher, Amazon,, JioSaavan and Gaana

Register now to get a cheatsheet for each episode!


Download Episode 6 transcript - How and when should I grow my business? [DOCX 23.93KB] or read here in full:

Intro music GUITAR HOUSE - Josh Pan (YouTube Audio Library)

CHRIS [00:00:04] This podcast series is brought to you by the University of Sussex. If you're curious about what makes some app successful and others not, this series gives you a valuable insight into seeing if your app has got what it takes. With the help of three successful at founders we'll be investigating and answering some of your questions. I'm Chris O'Hare, your host and app resident expert with 10 years’ experience in software development and founder of award-winning technology consultancy, Hare Digital. We've built Apps for businesses big and Small. This is how to make an app.

CHRIS [00:00:46] In this episode, we'll be talking about scaling your app. So, you've launched your app and it's been a success. You've validated that your idea is a problem worth solving and people are willing to pay for it. So, you could see a future to your app. Well, next, we need to build an infrastructure to allow your app to grow, otherwise known as scaling. There's two parts to scaling, scaling the technology and scaling the business, which we'll talk about that one first. But in essence, is everything you're doing now, but more of it. So, there are two approaches to scaling your business. You may wish to grow on your profits alone, otherwise known as bootstrapping, or you could take investment and grow at a much faster pace, but with a higher chance of running out of cash if you can't cover your costs with your profits. One study looked at over 3,200 start-ups and found that 74 percent of them failed because they tried to scale up too quickly. If you bootstrap your start up, they'll have more time to find the perfect market fit rather than just throwing cash at the problem. Be under no illusion that because your Start-Up solves the problem for a small amount of customers, it doesn't mean it's perfect for a larger number of customers to sustain the need for rapid growth. By staying small you'll show more finesse in eeking out the most of your cash and be more strategic in your approach. But obviously you may risk a competitor overtaking you and taking that market share. Growing your Start-Up quicker means that you can experiment quicker to identify what works and doesn't work. But don't underestimate the fact that managing larger teams is a far more complex process, and you'll probably need to have middle managers to do so. When you grow too quickly you could lose sight of the company ethos, which could be the differentiator between you and your competition. Either way, you're probably going to need to get help as you'll only have a limited amount of hours in a day. So, you'll need to hire employees or outsource your problems to others. My advice on this is to hold off hiring until it becomes detrimental to your growth. Why, you might ask? Well, you become ruthless with your time and make sure that the most impactful things in your day get done. It's incredibly easy to slip into managing people, rather working on the business, which at the end of the day is priority number one. Obviously, there's a limit to this advice, and if you need professionals to do the job in a fraction of the time, then it's certainly worth weighing up the time to cost benefits. It's also incredibly important to understand in detail what you're hiring for and what they need to do to get this job done. And there's no better way than if you've been doing it yourself. I've seen startups throw away money to employees or agencies who weren't needed. And that's because the founders weren't involved or didn't understand their job roles, so they couldn't see it, but always get professional advice. The amount of times I've seen businesses that have made bad decisions, it's almost always because they never got an expert to tell them what to do. One bit of advice could get them on the right path, saving a tonne of time and money, and don't spend money if you don't have to. The age-old saying cash is king still reigns true, startups run out of money fast and it's one of the biggest reasons they die. If you can elongate the runway, you'll have a bigger opportunity of succeeding. Now, runway is a startup term for how much time you have left with the money you have. And if you do have to spend try to cover your costs for profits or get investment, I never recommend borrowing money. You'll hear from our guests later of how they kept as lean as possible. The parts of the start-up that tend to grow first is operations, marketing and sales and of course, the technology team. These are the three most vital and time-consuming parts of a tech start-up. When it comes to the technology, you need to turn your MVP into something that can scale. To do that, you're going to need to figure out how many users your app can sustain today and how many new users it can cope with over the next few years according to your growth. And then you need to build out the infrastructure to cope with this growth. You're going to need to optimise a rough and ready code that was developed as part of your MVP to save time into something that is efficient and optimised so it doesn't fall over when your app gets featured on TV. You'd be surprised how many websites and software crash with some minor publicity. They didn't have a plan on how they would cope with it. You'll also need to have service that can balance the load across multiple server locations around the world. And not all developers are skilled in building out this kind of infrastructure. So, you'll need a technical team that is more diverse to cope with these differing technologies. You'll most likely need front end developers back end, app developers, devox, engineers, and now you're a bigger target. You're probably going to need to hire the services of a penetration tester, a pen tester, or try and hack into your app to ensure that other, more malicious hackers don't succeed and plaster your user's data across the Web or sell it to the highest bidder. At this stage you'll also want to expand out the features and to do this will go back to the loop of iterative development that we discussed in the first episode, where you'll continue this loop to test new ideas, find out what the customer wants and improve their experience. And this becomes your startup's development engine. The goal is ultimately to increase the amount of new subscriptions, and lower the churn rate. Now, churn is when people stop subscribing to your app. But for every feature you add, you'll also add another layer of complexity, something else to support when a customer asks about it and that it doesn't break any of the other features on the app already. Building another feature isn't just as simple as when you first started out. You'll have so many more things to take into account and this is why successful tech companies have hundreds of people just working on one feature. Now, when it comes to the operations team, this is all about the administrative tasks of running a business; from finances to HR, management to customer support. This can be a huge drain on your time. that doesn't add a whole lot of value to your business, but has to be done, plus it's incredibly boring. When, scaling try to automate a lot of these repetitive processes using systems, or you can outsource to specialists who have the sole focus of delivering that service or at the very least, delegate to others in your team. Figure out the time to cost ratio to work out if that investment is worth it and most of the time it will be. And we've already covered marketing in some detail in the last episode. But to scale marketing, you need to do more of it now. You'll have specialists for pay per click, for SEO, for social media, even conversion optimisation, but also use marketing to look at pushing into new market sectors that your app could comfortably serve but has been neglected because your marketing strategy beforehand has been focused on a niche. Also quite a milestone for start-ups is when they open up an office internationally but you may need to take into account different languages, translate in the app and adjusting the design accordingly, which takes on another layer of complexity when building out new features. Just remember, the bigger your app gets, everything else gets bigger with it. Earlier, I spoke with Peter Lloyd, co-founder of TRIM-IT, who was a student at the University of Sussex when the company was first founded

PETER [00:08:57] About six years ago I met Darren through an anonymous location-based app called Yik Yak, and he actually put out a post and he was like “I’ve got a bug with my code” and stupidly enough, I put my number online for everyone to see. But luckily enough, Darren actually contacted me and I met him in person and he said, I've not actually got a bug. I need you to make this app with me. This was at University, at Sussex, the following summer. We kind of developed this app and originally it was a booking platform for Barbers and we managed to sign up over 300 barbershops in Brighton and London. But we had this issue where we couldn't tailor the experience because we couldn't tell the barber what to do, they were just using our platform as a scheduler and people weren't getting their trims on time and we had a few issues. Then with our last 10,000 pounds we decided, let's stop this, let's do a crazy idea. And we decided to convert a Ford transit into a mobile barber shop, and then from then we've grown, we've built more vans, built more of a team around us.

CHRIS [00:10:11] So when you came up with the mobile barbershop van, what made you think that that was a good idea?

PETER [00:10:18] When we originally started TRIM-IT anyway, the idea was, you know, Darren was waiting four hours in a barbershop and he just didn't have the time. So that's always been a core part of our company. We wanted to be able to control the experience a lot more. We still wanted to save people time to actually, you know, let's make it even more efficient and bring the barber shop to the customer.

CHRIS [00:10:40] So you've now decided to buy a van. You've got a van. What was the next step in the process?

PETER [00:10:47] So we knew we needed to grow the business in terms of the amount of vans and also the amount of barbers running these vans. But as this happened, we were straight out of uni, we were managing these barbers, but we realised that we're not managers. You know, that's not our core task in life. You know, we're entrepreneurs. We like building technology. We like building products. We grew and hired more barbers, had the more vans but actually what we started to realise is, it wasn't scalable. You know, we would hit a limit, you know, if it was 50 or 100, we'd still hit that limit, and we wanted to get to 50,000 barbers using our platform. So we realised quite quickly that actually the way to do this was to franchise the model, you know, allow a barber to partner with us rather than working for us and also be able to enhance their experience and be able to, like, let them make more money. In a barber shop at the moment, there's three types of payment structures. It’s either commission, which on average is 40 to 50 percent of a booking, which is quite a lot, or it's renting a chair, which on average is 250 pound a week, or it's a salary model, which on average is about 20 to 25 thousand pound a year. With these figures in mind, we wanted to build a partnership model which turned into this franchise model where they would actually be able to make a lot more money than they were currently making in the barbershop and be able to feel like this is our own company. A lot of barbers are self-employed so, you know, they don't like being told what to do and we don't want to tell them what to do, we want them to grow with us.

CHRIS [00:12:32] You recently raised some money. How did you go about that?

PETER [00:12:35] So we recently raised one point one million. This was through the Future Fund scheme, which is a government backed scheme where they'll actually provide Risk-Free capital along with our current investors. So most of the investment came from one of our biggest angel investors. And we had a few smaller angel investors and a VC firm, which also put into this round.

CHRIS [00:12:59] So how many rounds have you currently raised?

PETER [00:13:03] So we've raised a friends and family round, precede a bridge round and now a seed round, which was the one point one million

CHRIS [00:13:11] In each one of those stages, what did you kind of use the money for?

PETER [00:13:15] We actually took out a loan from a bank for the van of 10,000 pounds. We created the idea and made the van and then we got into a situation where we were like, actually, now we need to find a barber. You know, we weren't sure what we were doing but we knew that this was a last pivot, you know, let's go for it and see if it works. After that, we built this van and then we were like, cool, we're all working at of our homes. I was still at university at this point, Darren was back in London. And then we were like, we need more people to do this and we need to actually have a place to do this in. So that's where we got our first office, which was in Brixton. And with the friends and family round, we were able to secure this office, be able to buy a couple more vans and convert them. But at this point, we were buying really old transit's and we got into a situation where actually, you know, they were breaking down. We're spending this money on actually fixing the van rather than actually using it to make revenue. Then we started buying newer vans and we used the precede round to do this and we actually employed a couple more people, but we kept the team really lean. You know, we didn't want to spend all our money at once. Darren especially knew that actually raising is quite hard for a very young team with a very early product. And thankfully, we brought on a few really big investors and our advisory team has grown with this and they've helped us to be able to raise more rounds in the future and also kind of given us the advice we need in terms of who to contact, when we should contact them, how to create a pitch deck. I remember at uni, like looking at all this kind of stuff, and it's very interesting how people that have been in the game this long know exactly what to do, whereas if you search online, you'll kind of get very different responses. So it's just really good to have the kind of mentorship and to have the advice so we can actually succeed and do it correctly rather than going out to people showing what we have and then rejecting us on the spot,

CHRIS [00:15:22] Talking to the professionals, talking to these investors, they imparted all this wisdom on you that you wouldn't be able to have got through Google alone

PETER [00:15:31] in terms of the Start-Up World and kind of running a business. Your network is, you know, one of the most important things. If you don't have that, straight away, start connecting with people, talking to people and getting advice.

CHRIS [00:15:43] Would you say that it was helpful to get this mentorship then?

PETER [00:15:47] A hundred percent. I think having a network and these advisors to mentor you is one of the most important things in running a Start-Up. They have years and years of knowledge on you that actually you can get in a second rather than making the mistakes like some of them did. But we don't have to make the same mistakes. It's like when you're younger and your parents are always telling you to do stuff, not to do stuff. When you grow up, you kind of realise that they're telling you not to do the stuff because they've made mistakes, possibly. And, you know that they don't want their child to make it as well.

CHRIS [00:16:19] Were they key to helping you hiring your team? Did they give you a lot of advice around that?

PETER [00:16:25] Our team's been quite tight anyway. A lot of the members of the team in the past especially, have been kind of friends, friends of friends, because, you know, we haven't had so much money. We haven't been able to just hire someone for 40 K, you know, and it'd just be like normal. We've had to really kind of all struggle together, build this company, which is bigger than all of us. So we weren't able to just, you know, go on to Indeed and hire the best of the best people for 100, 200 k. But we had to get really excited, invested people into the company and provide a little bit equity so they would believe in the product and work as hard as all the kind of founders did.

CHRIS [00:17:15] And so let's talk about your team, give us the reasons why you hired certain members of the team or why you have job opportunities for certain roles.

PETER [00:17:23] So currently the team is still relatively small, but I think it's really important to hire the right people and to hire people that are really engaged with the product we're creating and also excited to come to work every day. I know that sounds really cliche, but it is actually really important to a company. So currently in the team is myself as CTO, Liam COO and Darren as CEO. So under Liam we have Isabelle and Cam and they kind of form the operations team. So currently under myself we have Jeff, who's a senior web developer, and he was brought in about gosh it must be about four months ago. It feels like yesterday, to be honest. But he's an amazing developer. He's helped us build out our website currently building out our customer booking site and also helps us on the backend. And now TRIM-IT is getting bigger and the amount of products that we're actually producing is increasing. I really do need to take a step back on the actual development. I've been told by a lot of mentors and a lot of advisors being a CTO isn't just about coding and it's something I've learnt quite recently. So we've actually put out a job offer for a backend developer and their skill set will be creating and improving our node API using graphql to connect up all our products and also make sure our product is fully scalable. Currently, we're using AWS Lambda which is Auto Scaling and RDS Aurora for our database, which is also auto scaling. However, you know, when you're actually building an application and when you're actually thinking about how do I make it scalable, people always talk about making sure your service scalable, your database is scalable, but no one really talks about actually the other APIs you use, for example, Google for location based data, Twilio for sending out texts or even stuff like Intercom for customer service. But actually, it's super important for your systems to be as efficient as possible because it actually just costs you more money to use them. And I know it just sounds really simple, but at university I remember getting taught Big O Notation and it was all about how many times one line runs on your programme and they always explained it that, you know, you want your code to be really efficient really fast. But the thing that clocked it for me is that issuing code is superefficient. Most of the time we could actually half or quarter the cost per request on your application.

CHRIS [00:19:57] So it's really interesting how you're talking about making your code more efficient so that when you're retrieving this information for the likes of Google or the likes of Twilio, so if anyone knows, Google offers these map locations and you've got Map Box, you're talking about maps and also talking about Twilio, which is sending text messages. If you condense the lowest amount of requests you can, basically what you can do is then reduce the cost.

PETER [00:20:22] Yeah, definitely. So going on to our app even and checking for any availability around your area does cost us money. So we need to make sure that we're doing as much stuff as possible to make this as efficient. So, you know, if a hundred people come onto the app and it costs a penny to load up the availability system for example, a pound isn't too much. But if a million people start coming on to the app, then hundreds of thousands of pounds, it's going to get unscalable and especially if they don't book. So we do a lot of things to estimate travel times before asking Google. So if anyone's listening has actually been to London, you know, you can't drive 60 miles an hour in London. You'd be lucky to drive 20 miles an hour through Central. So what we actually do is we do our own maths. We calculate the distance by longitude and latitude coordinates or two different points. And then we say, OK, cool, if you can't drive 60 miles an hour across London and fill it in and there's no point talking to Google and asking, can you do the actual travel time.

CHRIS [00:21:29] If you're asking for things over the Internet, obviously that can get quite slow, if you're requesting constantly, what you can do is by slowing down these requests, you actually can speed up your app as well. That's something we noticed in a recent project that we did. So what about Darren and his part of the team? That's marketing and sales, I'm assuming?

PETER [00:21:50] Yes. So Darren's in charge of more of the kind of sales and marketing side of the company. And under him we have Maz, who's the head of marketing, and we also have Sam who does our social media.

CHRIS [00:22:03] I would say that that's an important part of your growth going forwards. Are you developing processes, systems or SOPs, standard operating procedures to help you guide and automate your business going forwards?

PETER [00:22:16] Definitely. I mean, in terms of even marketing, we send out a lot of automated processes, a lot of automated push notifications, email marketing, text messages. Currently, what we're doing is creating a system actually, which predicts when someone needs a haircut. So I know that sounds pretty simple. You might get your haircut every four weeks, two weeks, six weeks, and just kind of automatically sending out a push notification when it's due. But actually, what we want to do is it's all about creating the most efficient route for the barber, because at the end of the day, we want the barber to make the most amount of money. What we can do is we can actually use their previous longitude and latitude coordinates or previous bookings and their previous booking history in terms of when they'd like to normally get a haircut, in terms of if it's every Monday at five o'clock and send a push notifications through certain events prior to them booking. So actually we can say, “hey, Chris, we know that you've got a haircut due soon, why don't you booking this lot and we'll give you a free travel fee” because, you know, it's more efficient for the barber and actually he might be able to fit someone in.

CHRIS [00:23:25] How did you know I needed a haircut? Thanks to Peter Lloyd there, co-founder of TRIM-IT. So, that's the end of the How to Make an App series where we've covered why you might decide to build an app, coming up with your idea, validating it and then prototyping your app. What is an MVP and creating your design specification, how to get your app funded, whether through an investor or grants, how to get your app built by an agency or freelancer, launching and marketing your app and how to scale your app to more users. And if you'd like a cheat sheet for this episode, please go to . It's been a pleasure to bring you the six-part series as we went on a journey. Big thanks to my special guests, Phil Watton, Ian Wakeman and Peter Lloyd, who shared some incredible insights from their own experiences. And thanks to Georgina Smith and the University of Sussex for organising this great podcast. And thanks to our producer, Graham Seaman, who made us sound amazing. That was How to make an app. This has been a fresh air production for the University of Sussex.

Previous Episodes

Episode 5 - How and when should I launch?

When to launch your App and things to include in your launch strategy. This episode is filled with marketing tips that will help you to build your app audience and keep them! Chris O’Hare in discussion with Georgina Smith.

Subscribe now!

Spotify podcasts badge Google podcasts badge Apple podcasts logo

Also available on Deezer, Stitcher, Amazon,, JioSaavan and Gaana

Register now to get a cheatsheet for each episode!


Download Episode 5 transcript - how and when should I launch [DOCX 21.14KB] or read here in full:

Intro music GUITAR HOUSE - Josh Pan (YouTube Audio Library)

CHRIS [00:00:04] This podcast series is brought to you by the University of Sussex. If you're curious about what makes some apps successful and others not, this series gives you a valuable insight into seeing if your app has got what it takes. With the help of three successful app founders we’ll be investigating and answering some of your questions. I'm Chris O'Hare, your host and resident app expert with 10 years’ experience in software development and founder of award-winning technology consultancy, Hare Digital. We've built apps for businesses big and small. This is how to make an app.

CHRIS [00:00:45] In this episode, we'll be talking about launching and marketing your app. And with me is Georgina from the University of Sussex. She is typical of many people who have thought about making an app but don't know where to start. Georgina is going to ask me the kind of questions that someone starting out would like to know.

GEORGINA [00:01:05] Okay. Thanks, Chris. When should someone think about launching their app? How do you know when you're ready to launch?

CHRIS [00:01:13] Well, Georgina, launching your app should be when you still feel uncomfortable. It's an effective motivator when something is live as it forces you to get things moving, get things done. The book, Lean Start-Up, preaches that you should always ship early and ship often because without that experience of going live. You won't learn your lessons from real life customers to make a killer app.

GEORGINA [00:01:37] Okay, so I need to not wait until I feel comfortable. But where's a good place to start?

CHRIS [00:01:42] Well, the prelaunch is where you need to start and that's where you get everything ready to reveal your app to the world. First, we need to make sure that you've tested your app with different scenarios and different users. You want to make sure that you've caught as many of those critical bugs as possible. Not only will critical bugs fail the app approval process, but if people get the glimpse that it could be unstable, it's highly likely they'll lose confidence and not return. Now, there's a stat that says 77 percent of people don't return to a newly downloaded app after 72 hours. And if you want to outsource this quite laborious task, you can hire a testing company, to come and do this for you, and they will compile a detailed report of all the bugs and how they can replicate that process. And when it comes to getting your app out there, we need to build an audience for launch day. Throughout this process you need to think about how you're going to get found by your ideal customer. And you know those website pages we spoke about in the first episode? Well, you'll need to select the best one to pick up as many email addresses as possible, let people know that the app is coming and they will receive a discount or a bonus if they sign up on launch day. And when that day comes, send out an email to all your email contacts that the app is now live and include obviously on the website links to the App Store pages so people can download the apps. Another great strategy is to create a weekly newsletter telling your ideal customer tips and tricks about the problem that your app solves. If you've built a meditation app, for example, send an email newsletter about how to reduce stress. Now, content marketing is a key part of your launch strategy where you create these long form content around niche areas that adds value to your ideal customer. Also improves the search ability of your website. This is where you textually optimise the website for SEO and for jargon busting purposes, this is search engine optimisation, which helps your ideal customer find you using keywords that they would search for on Google. But don't expect a lot of traffic from day one. But over time this could be a great asset for getting website hits. Now, another way to build an audience is to document the process of building your app as you go along and be as open as possible, include those trials and tribulations and how you've overcome them include all your successes, your emotions, and how it makes you feel, and make sure to include tips of how to build an app after you've learnt the hard way. People really buy from people and they love a good story. And this openness is marketing dynamite. And if people want to publish articles about you, make it easier for them to do so. Create a media kit with all the key information about your app, summaries, features, your story, logos in different formats and sizes, screenshots of your app and even a video trailer if you have one. Journalists will ask for this information anyway, so you might as well prep for it in advance and put it at the bottom of your website. You can also create a formalised press release of your app launch ready to go out when your app is live and you can get them distributed across all the major publications and media using a distribution website like PR Newswire. Make use of social media post to advertise your app. It's a free advertising platform. Short video clips will get the most interactions and used niche hashtags that target your ideal customers. Going back to the persona that you created earlier, use this to guide you when making your posts, what is it that they would like to see? You can also sponsor these posts to boost their reach to your target audience. This can become expensive if you're not laser focus on who you want and if you want to be really clever, you can change the social media post depending on the hashtags you're targeting. Now, these social media posts won't do very well without interactions, so get a launch team of friends and family to boost the interactions of your social media posts by liking, commenting and sharing them. The social media algorithms will love this and dramatically boost their reach to others in your networks. The way these algorithms work is that they send it out to a small section of people, see how they react to it, and if it's popular, they'll send it out to more people, creating a feedback loop to keep boosting to bigger and bigger audiences.

GEORGINA [00:06:10] OK, so there's a lot that I can be doing to build my audience and help this launch be as successful as it possibly could be. So, people talk about optimising your app for the App Store. What do they mean by this?

CHRIS [00:06:24] Okay, this is known as ASO, another acronym otherwise known as App Store Optimisation. It's very similar to SEO, actually, but targeted at the App Store and their algorithms. Now, your app's profile is the only way you're going to get higher up on the store rankings. And the higher up you are, the more likely people will discover your app. So, it makes sense to optimise your app profile. Find the high traffic keywords that your ideal customer will likely be looking for. Have a look at your competitors to see what keywords they're using and there's a high chance that they'll be using the best keywords for your ideal customer. And you can use a website like Sensor Tower to help you find these keywords. Then you can use the best descriptive keyword in your app title after the name of your app so your customer knows what your app is for. And keep note of the high traffic keywords because we'll need to add them to the description. And bear in mind that the customer will be reading this to make a judgement that your app is fit for purpose and is worth downloading, right. And make sure to describe what your app does, what problem does it solve and why is it worth it? And make sure to include any scientific backing or awards. Don't be too wordy as not everyone reads a wall of text and also make sure to pick the right category that your customer is likely to find your app. You can also do high quality screenshots of your app as this is a key download indicator. App makers have gotten very clever with how they display their apps, utilising the horizontal image gallery to display a large image separated into chunks. You could also include some of the key Problem-Solving features of your app in these screenshots so they can quickly identify if it's fit for purpose. A short video trailers are also really effective in getting across the useful features of your app without the viewer giving too much effort to read a wall of text, but also significantly raises the quality in comparison to your competitors, who are probably likely not to have spent time on this. It may sound obvious, but ensure you have a striking icon for your app because remember, your app is going to be sat alongside a lot of other apps and you want it to stand out, otherwise it's going to get lost and forgotten. And last but not least, reviews, right. Not only does reviews help people decide whether this is a good app or not, it also helps the store decide whether to boost its ranking. Use your launch team of family and friends write reviews for your app. And if you think this is underhand, trust me, all the other apps doing it. And it's worth encouraging others to write a good review for maybe a special offer or bonus.

GEORGINA [00:09:10] Okay, but what about the infamous App Store review?

CHRIS [00:09:14] Well you're right Georgina, we're still going to need to get your app onto the App Store. And Apple has a pretty stringent validation process. Google not so much. And you can be knocked back for some basic things so make sure to have a read of the guidelines so you mostly know what to expect. Firstly, you're going to need to buy an Apple or developer license, which is 99 dollars a year, where Google's is only a one off 25 dollar payment. Next, you're going to be needing to fill out all that meta information, such as titles, descriptions, bios, keywords, screenshots as per the App Store optimisation advice that I spoke about earlier. And then you upload the App Store, submit it for review and make sure you schedule a release day as you don't want it going out before the launch date. Unlike Google's automated review process, Apple's review process is done manually by actual humans, and it can take around two to three days for approval or rejection, and bear this in mind, if you have any imminent launch dates. And if you do get rejection, which is more than likely, it will, I don't think I've ever had an app launch without a rejection. You just need to fix their objection and resubmit again. Could take another two to three days to do so. But don't fret about it too much. A developer will have knowledge of how to do this.

GEORGINA [00:10:33] OK, so I've launched the app. What next?

CHRIS [00:10:37] Celebrate. Have a drink and enjoy the amazing feeling of seeing your months of hard work on the app stores, but also the anticipation of not knowing what's around the corner. Now, most of the stressful parts of a launch is in the critical bugs. You don't want your customers having a bad experience. As I said before, and if there are any bugs, make sure you get your developer ready to fix them ASAP. And likewise, if your app is popular, your developers should be monitoring its ability to handle all these new app users. It's worth having a maintenance agreement with the developer to mitigate a spike in costs at this stage. And once everything is settled down and your launch strategy is going well, it would be a good idea to apply to be featured by Apple. Now, this is very difficult to do, but if your app is unique and of high quality, then this will give your app a much-needed boost of exposure as that will post your app on a new and noteworthy section. You can also get influencers in your space to use your app and review your app. Otherwise you can pay to sponsor them.

GEORGINA [00:11:38] OK, I celebrate. I work with my developer to make sure that any bugs are fixed so that my users continue to have a positive experience. And then I really try and push exposure of my app to get more people using it. Excellent. How can I tell if my app is doing well?

CHRIS [00:11:55] Good question. So, your developer about to give you access to metrics such as server performance and app store downloads. And this is important to baseline your performance when you're applying your marketing energy and your budget. And you can see how well that works and how you can replicate that growth in the most efficient way next time. You can also track the downloads of your competitors and see if there's a correlation between your app and theirs. And over time, you'll be able to see if people are sticking around and whether your app is growing. But I've always advised that the largest part of the startup's time and budget should be on marketing and PR because if you don't have customers, you don't have a business.

GEORGINA [00:12:33] There's quite a lot going on here. So, what should someone expect to spend at this stage? Like how much should this stage cost?

CHRIS [00:12:42] First of all, don't spend more than you can afford. Obviously, you need to build a functioning app and that's fit for purpose so that should be your budget's priority. But everything else has a cost to return ratio. So, try everything. Once with a small budget, measure what has impact and double down on what works. If you do it correctly, you should see that for every pound you spend, you should get at least one pound or more back in sales. But if you want to focus on the free things like there's no harm in doing so, it would just take longer to get your app out there.

GEORGINA [00:13:13] What would you say is the most effective way to spread the word about an app?

CHRIS [00:13:18] Most people won't like this, but it's basically good old-fashioned PR. Just get out and talk about it in many places as possible. Go on an app launch tour and be a guest on podcasts, webinars, go to conferences, try and get into newspapers, on TV, even the radio. Basically, everywhere there's an audience, just ask to be a guest on them. Target where your ideal customer will hear you first and foremost, this will give you your greatest impact and more than likely this is going to be free. It's just your time that you're going to be spending.

GEORGINA [00:13:50] What can you do to encourage people to commit to the app and put some money behind it?

CHRIS [00:13:55] Well, this is a really hard question to answer, because if it was easy, everyone would be millionaires. So, I'd flip this and I would say, what would make you commit money to an app? And I think it usually comes down to these four pillars. Trust, is it an app that comes from a reputable company, are the reviews good? The next pillar, the accolades, has it won awards? Has it been backed by famous people or academic research? Third one, quality does it work as intended? Does it crash? Does it not crash? Does it look like it's high quality? And the last one would be problem? Does it save you the time or money that you're trying to solve? And ideally both of those at the same time.

GEORGINA [00:14:38] What about pricing your app? How should someone approach that how should they decide how it's going to generate revenue?

CHRIS [00:14:48] Well, I don't like to buy an app from day one. I don't know about you, but I need to be wooed and comforted that I've made the right choice. So, make sure your app is free by either giving your users a seven- or 30-day free trial at the beginning. Or you can do a free limited version of your app. They call that freemium. And afterwards, what's the monthly subscription they would pay for? Well, you can use your insights from Episode one where you found out what your customers said they would pay for. And don't be afraid to test this, especially at a higher price. And a use special offers to reduce that price for a limited time period.

GEORGINA [00:15:25] Okay, great. What about version updates? Like I've heard that you need to release these quite regularly. Is that important?

CHRIS [00:15:33] I guess this is about showing users that you're continuing to update the app and has it been neglected? You can see some of those apps that have been neglected for a year or so. And this is a good indicator of trust and quality and they’re more likely to continue paying for the subscription if you can see that the getting apps release regularly. But what you can do is part of the maintenance agreement with the developer is set a roadmap of functionality so if they don't need to fix a bug, they could just continue working on building new functionality and release this over time.

GEORGINA [00:16:06] Where can things often go wrong for people at this stage?

CHRIS [00:16:09] I think it's really important that you listen to your first customers. So I guess not listening to them is where it can go wrong and not acting upon the feedback, which is a really big mistake. So, these first customers are your early adopters, and they took the leap of faith with you, even though they know you're not a well-established company and you're a new app. So, you need to treat these people with a lot of love and respect, and there's a startup philosophy, that you should find your 100 true fans who will buy everything you create. And to do this, you need to build a strong relationship with them and talk to them regularly, make them happy. Sounds simple, right? And if you're wondering how to do this, it's not rocket science. Just pick up the phone and talk to them. Thank you for listening. And if you'd like a cheat sheet for this episode, please go to . In the final episode, we'll be talking about how to scale your app.

Speaker 3 [00:17:12] Currently what we're doing is creating a system which predicts when someone needs a haircut. It's all about creating the most efficient route for the barber because at the end of the day, we want the barber to make the most of money. So actually, we can say, hey, Chris, we know that you've got a haircut due soon. Why don't you book in this slot and we'll give you a free travel fee.

CHRIS [00:17:32] This has been a fresh air production for the University of Sussex.

Episode 4 - How do I build an app?

Chris O’Hare in discussion with Phil Watten, founder of MAVIS about his experiences of building an App, the importance of listening to the user experience and the benefits of software as a service (SaaS). This episode explores different App building options to turn your idea into reality.

Subscribe now!

Spotify podcasts badge Google podcasts badge Apple podcasts logo

Also available on Deezer, Stitcher, Amazon,, JioSaavan and Gaana

Register now to get a cheatsheet for each episode!


Download Episode 4 transcript - building [DOCX 26.18KB] or read here in full:

Intro music GUITAR HOUSE - Josh Pan (YouTube Audio Library)

CHRIS [00:00:04] This podcast series is brought to you by the University of Sussex. If you're curious about what makes some apps successful and others not, this series gives you a valuable insight into seeing if your app has got what it takes. With the help of three successful at founders we'll be investigating and answering some of your questions. I'm Chris O'Hare, your host and resident app expert with 10 years’ experience in software development and founder of award winning technology consultancy, Hare Digital. We've built apps for businesses big and small. This is how to make an app.

CHRIS [00:00:45] In this episode, we'll be talking about actually building your app. And for most of you, this will require getting a developer if you don't have a technical co-founder. You will even need to pay an agency or a freelance developer or maybe even employ a developer to build your app. An agency is a company with a team of experts in app development. They'll be able to give you a wide range of skills under one roof from designers, marketers, developers and project managers. They're a team of specialists working on projects as if they're on conveyor belts. And as a result, they're more likely not a certainty. But to be more efficient, more reliable, deliver higher code quality, along with being more knowledgeable about app specialities and any common pitfalls. Of course, this comes at a cost as you'll be paying for a team of professionals and their accompanying overheads. Alternatively, a freelance developer will be cheaper initially, but if they're off sick or they decide for some reason they can no longer continue building your app, then you're left with quite a headache to try and replace them. And you'll need to get another developer up to speed in the short amount of time. You also run the risk of lower code quality standards as they don't have anyone checking their work, potentially lead into problems down the road. Because freelancers tend to not have a rigid structure. They tend to be more agile, dipping in and out when you need them, and helping deliver the project that's fit for purpose, if requirements change over time. They also tend to have shorter time scales and can fit in your project a lot quicker than agencies who have these long pipelines of work that they need in order to survive and ensure that they can pay their employees. So how do you decide? Well, my advice is to go and talk to them and ask all the questions that concern you. Also, get recommendations from your technical friends and also follow up on references, there's no harm in talking to more people to get advice about your project and the best approach for you, your timeline and your budget. You may even decide to employ a developer full time to build your app, the kind of developer you'll need is a senior full stack developer, which is not cheap. And they average around 45 K a year plus national insurance contributions, will cover what full stack means shortly. But they'll also need to be a senior several years’ experience to be able to manage themselves. Now you may be able to offer equity options for a reduced salary, but you need to consider that this is a full-time position and therefore there needs to be enough work for them. But if your app doesn't succeed as quickly as you'd hope and you can't afford to pay the developer, they’ll have to leave along with all that intimate knowledge that they've accrued building your app. So once you've picked a developer, you're going to need to understand some of the technical jargon. First of all, how does an app work? Let me give you an example of an app that I use daily, my banking app, the app is installed on my mobile device, in my case, an iPhone which is downloaded from the Apple store. This mobile app is called the client, also known as the Front End. And once I open up the app, the first screen I see is my dashboard with my latest balances, and that took microseconds to show me. What the app has done, is taken my request that I want to see my dashboard balances. It sent this off to the cloud server where there is another piece of software running, the cloud is just another word for Internet. But you'll hear terms like AWS, which stands for Amazon Web Services, and yes, they are the very same ones you buy all your gifts from or another popular one is Google Cloud. Now, these are cloud server providers and they're commonly used by developers. The software that is running on this server is the API, also called the back end. And it's where the brains of the app lives. The API or application programme interface checks that this is a proper bonafide request from the app, by checking all of its security credentials, the API will then check what I'm asking for and in this case, my latest balances and fetches that balance information from the database. It will then format it, package it up and send it back to the app on the mobile device. The app checks it's a bonafide message, makes it look pretty and displays my balance to me in a way I can understand. Now, coming back to what a full stack developer is as a skill set, they are able to build the infrastructure across the whole development stack, which includes the front end, the app, the backend, which is the API and also the server. You'll also need to understand the different technologies that you can use to build your app. The most widely used is the traditional native route, and this is where an app has been built in the code that the platform has been designed for. And this would be swift for Apple's iOS and Java for Google's Android. The obvious drawback is that you'll need to build two separate apps for both platforms using two different coding languages, which will obviously increase the price because you'll need to build two apps. The major benefit is the apps will behave exactly as you expect, and you can build the app to use all the special features, libraries and sensors that have been designed specifically for that platform. IOS has their own interesting features and so does Android. When Apple released the augmented reality camera, you would be able to use these from launch riding that publicity wave of when it first released, these apps are also more efficient in terms of battery life and performance, giving the user a better experience. But most apps won't need this level of quality for the MVP. The next route is a cross platform app such as Xamarin and or new technology like React native. Now, how these work is that you build an app in one language and it will be converted into native apps for both iOS and Android. If you want to use a particular feature or sensor, you have to use the cross platform's plug in to be able to interface with this feature or sensor. The experience won't be flawless compared to the native route, as you'll experience strange bugs and they're usually slower and the user interface won't look as good, but it will be cheaper as you'll only need to build one app. The other route is a progressive Web app, which is basically a website that has been built to look like a mobile app. Now, this isn't as well supported as the previous two options as you can't always get them onto the Apple App Store. Google doesn't mind so much. Plus, you can't access all the special features or sensors of the phones. So if you want GPS notification and access to photos, basically anything you can do on a browser that works fine. But if you want anything else, you're going to struggle. The main benefit is its hell of a lot cheaper to develop as you can get a web developer to build your web app and mobile app at the same time, it's a great option if you want to test the prototype or an MVP. The last option is a no code app builder. A no code builder allows you to build an app using a drag and drop user interface with no experience of code necessary. If you ask me a few years ago, I would have said no way, but no code builders are getting better and better over the years and now I can really see the benefits. But it's not as easy as it sounds. You still need to provide the logic of how the app will work and you are limited to the templated designs and structure that you're given. If you struggle to build a drag and drop website, then this will equally cause the same kind of problems. When you're building your app, you're going to hear about something called Agile Project Management. This is a set of methodologies that encourage projects to stay flexible. Now, the general idea around these is to make sure that you have an iterative approach to managing projects. You focus on working on small batches, you're transparent about the work progress, that you work with the customer closely and you're getting feedback as fast as possible. You'll also hear something called Scrum, which is the most popular type of agile project management. In scrum, you have a product backlog, which is the project to do list. Tasks are picked from this backlog to work on for the next two weeks, which is called a sprint. The aim is to pick tasks that will deliver a shippable working feature after the two weeks is finished. Now, this is managed by various team members who take ownership of certain parts of the project, including a product owner and scrum master. So where things go wrong for people at this point is when the vision is not clearly communicated and you don't get the product that you want. Therefore, you need to make sure you're a part of the process with the developers and that you catch things that get missed. Get regular updates and see the product as it progresses, so one of the most common questions I get asked is how much does an app cost and how long does it take? And you’re going to hear one of those annoying answers. It depends. And that's because it's subject to not just the amount of features you want, but also the difficulty that it takes to create those features. Even if your app seems straightforward with a couple of buttons on the surface, the backend logic could be incredibly difficult to build. Remember, you're essentially paying for someone's time to do this. So the more time they take, the more it will cost. Most of the time there's also a minimum build time depending on the agency or developer. But I haven't seen a project that takes less than around three months. In terms of how projects are billed, they can even be billed as time and materials which you're paying for depending on the time spent on the project or you can opt for a fixed project cost. But more time is spent on the scoping phase of the project to ensure that the developer catches everything. Usually this approach includes a mark-up to cover any risks, which can be something like 25 percent extra. Earlier on, I caught up with Phil Watton, founder of Mavis, a mobile production studio, up to hear about his experience of building an app

PHIL [00:11:35] We're a technology company primarily focused on cloud production for the television broadcast industry. The best way to think about it is if you ever see a live show being made, maybe at a football ground or, say, a theatre, you'll notice some big trucks in the car park and these big trucks are full of equipment, full of people making the show. They've got lots of cables coming in out of them. And what we've done is we've taken all of the equipment in those trucks and we've put it in the cloud. It's all virtualised running in the cloud. This means two things. Firstly, you don't need to have those trucks. If you're now making a TV show, you just have to connect your cameras to the cloud. The second thing it means is that all the people that have traditionally driven to the car park no longer have to do that. They just connect to the cloud from home. And in our case, they use a suite of apps to then control the cloud based virtualised equipment. So it means you can make all sorts of programmes from all sorts of distributed teams all over the place without the need for this big capital amount of equipment.

CHRIS [00:12:39] What did you think of the idea of using apps as the mobile platform for choice?

PHIL [00:12:46] Well, we were doing a load of single camera production actually at the time when we would go off to a location, we'd do a bit scouting, we'd film a bit of a rough cut with an iPhone and then a couple of weeks later would send a crew along. And what we discovered was when we looked at the footage we'd made on the iPhone, it wasn't too bad. From a narrative point of view, it was really great because actually it was much more creative, much more flexible than using a big crew. And we thought if we could just control the iPhone in the same way that we could control the movie cameras, then we might actually find it so usable, proper camera. So we decided to have a go at building some technology so we could make it work, which we did. We then thought, well, this is actually quite a nice little product. Let's pop it on the App Store and see if somebody would like to buy it. Now, I'm glossing over quite a lot of work when I say pop it on the App Store. Obviously this takes quite a long time to take from a bit of a prototype to a product, but we did it. To our surprise, somebody else bought it and then somebody else bought it. And before we knew it, we had quite a lot of people using our apps, broadcasters, filmmakers, and it started to make quite a lot of money. But we were spending all our weekends, evenings, I mean, you know that moment between breathing in and breathing out any spare time when you're not doing anything else, we were spending working on it and still trying to, you know, do our day jobs. And we realised that we had basically a choice either to give up and take the money and just have a massive party or to reinvest the money and try and turn it into a company. So that's what we did. We hired our first engineer. We got an office in town, a little office that absolutely stank of poo! So, we very, very quickly got another office and we started growing the product. But we very quickly realised that we just got an app and we'd brought all the features of a professional camera to the app. There wasn't really anything else we could do. It was a standalone thing and we really wanted a way of growing this outside the app. So we started looking around other things we knew about and how we could maybe take the same approach. And we said, well, you know, we know a lot about multicamera live production. We know a lot about virtualising stuff because we've just done it on the iPhone. Let's see if we could virtualise multicamera life production equipment and put it in the cloud. And that's what we did. We built a prototype first and took it round to some industry angels who enabled us to get our first round of investment. We then made a beta version of it. Then we got a second round of investment, actually, right in the middle of a pandemic. So that was a pretty good achievement, I think, on the guys that did that. And we are now in the final stages of productising and bringing the thing to market. So we started off with one engineer and we've now got a total of about seven of us, not all of whom are engineers, but pushing that forward now to roll that out as a product.

CHRIS [00:15:32] So why do you focus on software as a service?

PHIL [00:15:36] Software's got itself a bit of a problem whereby people want software, they don't really want to pay for software, but they want free updates for life. This is a big issue because you can't run a business where nobody wants to pay for your product. One of the reasons is that people view digital products and physical products in a similar way but get confused. Say, for example, you have a loaf of bread. It's a tangible thing. You know, it's flour, yeast. You know, you can eat it and you're happy to pay for it because, you know, you pick it up it weighs something, but software is completely abstract, it doesn't even exist, unless he's actually running inside an environment and because of that, I think people feel it should be free because he doesn't weigh anything. But in both cases, they forget the amount of effort that's put into the factory, you know, to make a million loaves of bread a day, you've got to have a big factory that's been designed, built and got people working in it. The same thing goes for apps. But because it's not seen, people don't join the dots really. Software as a service is quite a good thing because it does two things. First of all, it means that your software isn't running on some random environment somewhere. It's not running on a phone or a computer that you don't understand or you don't know what other software is there because you are running that on a machine or on a number of machines, actually, that you're provisioning in a way that you understand and can control. The second thing is you are taking away a load of effort from the end user and saying all you need to do is push this button and your whole system will work. So because of that, people are happy to pay for it because they can see that you are doing some work that they are no longer having to do. So they pay every time it's being used and they're very happy for that. And we as developers are very happy for that, because every time a product is being used, we are being paid. So it means that we get a very good life cycle. It's constantly up to date. It's always state of the art. We always know it's going to work because we manage that end to end a system.

CHRIS [00:17:29] It seems iOS has been your main ‘go to’, but has that always been the case?

PHIL [00:17:34] Well, we don't actually only focus on iOS now. The first app we built was focused on iOS for two reasons, a) Noone on Android will pay for anything. And secondly, we were doing very low level hardware stuff using video and audio that is very, very difficult to do if you don't understand the hardware. And we looked at doing an Android equivalent and we'd have to produce a specific one for a Google phone, a specific one for a Samsung phone, a specific one for Huawei phone. We'd end up having to produce multiple different versions of that app, even though it would just look to us like it was an Android app. So coupled with the fact that nobody really wants to pay for it. And we have a lot of peers in this industry that have Android apps as well. And they'll all tell us that they wish they'd never done the Android app because it just doesn't make any money. So from our point of view, focusing on iOS was the easy choice because we understood the hardware and people would pay for it. That's not where we are now. We have a good core of stuff on iOS and Mac OS. We also have Windows versions and we will be bringing some small functionality to Android as well in the near future.

CHRIS [00:18:41] When you're making these apps, are you building them natively using swift or are you looking at cost platform technologies?

PHIL [00:18:48] Well, we actually spent quite a lot time looking at how we could do a cross platform, but actually we use swift and Swift is very good language. I really like Swift is very good for software engineering in general, it’s a high-level language. But that will compile down to a really tight set of instructions. In fact, if you write something in Swift and something in C, you will quite often find the SWIFT will compile quicker. In fact, you can do swift and assembly experiments and I can't get assembly to be quicker than swift. I mean, I can get them to be the same, but it does optimise really, really well. But at the same time, it also gives you some high-level constructs as well. So it's a nice language that covers all the areas and you can connect to C and assembly and C++. You can do all sorts of stuff. And it's a really nice language to work with on iOS and Mac OS, but it’s also open source. So we also use Swift on our server. We use embedded software, we use it on Windows and we started to look at cross platform things, looking at all sorts of different cross platform technologies to see if we could build some of the interfaces once and just repurpose them on other devices. But we realised that due to the networking that we need and due to the video and audio processing we need, we couldn't actually do it at the quality that we wanted that our users were demanding. So we built our own cross platform system really based on swift, C and a little bit of other stuff around the edges. So we have a sort of environment that we've built the cross platform bit. We can therefore make some of our apps and certainly the desktop apps for Mac OS and Windows as building one up. But we know how to do the low-level bits for each individual operating system where we need to.

CHRIS [00:20:31] Give us an understanding of the infrastructure of how your app works in terms of the communication with the server and down to the app.

PHIL [00:20:39] The pro camera, the original app that we made had no external communication. It was just one app, actually. But the way these apps work, they are remote controlling the cloud infrastructure. So the cloud infrastructure is a load of virtual equipment and the apps remote control it. Now, there are some web technologies around that will help you with this, but actually we can't use those because it doesn't really fit with the real time nature of our system. So we actually split our system into two parts. We have a real time system and a non real time system, the non real time system we actually run a set of technologies which are referred to as Serverless, this is all AWS. backed and Serverless means that you can produce a unit of functionality, one sort of operation, you then host it, you just give it to AWS and they run it when you want it. So you say, oh, I want to run this function. They just run it. You don't have to worry about any infrastructure, any servers running underneath it. They'll deal with all that for you. So you write one of these little functions pop it online and then all you do is pay for the time that that function is executing. So it scales really, really well and it's really cost effective because the less people use it, the less you pay, the more people you use it, the more you pay. So it's really nice, but that doesn't really work in a real time environment. What happens when you want the real time environment to run and you actually want to make a TV show, you sort of hit a button and then in the background we spin up a whole infrastructure of virtualised equipment to run. Now we have to process video frames, every single frame and audio frames, every single frame, because if you drop something, it'll look and sound bad. So we've got to not drop video or audio frames. So this has to be very real time. So therefore, all the apps will connect to the real time platform with a bespoke synchronisation system that we've had to make to enable the large amount of data that's going both directions. It's a bit like telemetry. You know, there's large amounts of data that's going in both directions constantly that has to always stay in sync and enable multiple control surfaces to understand what's going on in the cloud and therefore give you the appropriate feedback as to what's going on. To enable us to move video and stuff around the open Internet, we've also had to develop our own video transmission protocols. It's a specific one actually called MLSP, which stands for the Mavis Live Streaming Protocol. The Mavis Live Streaming Protocol is a way of getting very, very low latency, very high reliability, open Internet connectivity of video and audio so you can put a camera at a football ground, connect it to the cloud with MLSP. and it will make sure it gets there. I think we can do glass to glass in about seven frames. So it's pretty quick.

CHRIS [00:23:15] So when you first hired a developer, were they a freelancer? And why did you pick a freelancer if you did?

PHIL [00:23:21] So our first employee was a full time engineer. Actually, we wanted a full time engineer because we wanted to grow the company and we don't want to necessarily outsource that. But we do use freelancers for specific parts of the journey. And one of the things is graphics design and user experience design. Both are really, really important. And we don't want nonexperts doing that job, but we don't have enough work to permanently hire graphics designers and user experience designers. And also a lot of work is done in the graphic designs and user experience space, which will impact a vast amount of development time. So actually it's very bottom heavy where the UX and graphic design can maybe take a month or two and that can spawn maybe a year's worth of development. So it's more efficient for us to employ the experts where and when we need them and keep the core business in-house. And one of the things we do with graphics design specifically, actually, is we will pick different graphics designers for different things. So the graphics designers that we use for drawing the buttons and the faders and all sorts of interesting things like that on the apps, that's not the same team that does all our marketing and web and brochure type content, because that's, again, a different flavour. You kind of want the people that are expert in their areas to do that thing because they will bring a lot to the table and it's much, much better I think, even the freelancers can be a bit more expensive than having someone in-house. I think you get a better job when you have people who love what they're doing working on your product because you get their passion and their experience working on your thing. And I think that's great.

CHRIS [00:24:56] So how long did it take to develop the Mavis app?

PHIL [00:25:00] As it's a software, as a service, it's never going to be finished. It's taken us about two ish years, I think, to get to this point. The phone app we developed in about nine-ish months, I think. But this one's taken a lot longer because we've had to develop so much more bespoke technology. But we don't ever perceive this as being developed. We're currently in our going to market stage. So it's just in a release candidate stage, actually. So we're in a sort of version one, but we are already working on versions two, three and four, and it will continually evolve. And because it's software as a service, because we can do that, will evolve the architecture along with the software and the apps themselves.

CHRIS [00:25:38] How did you determine what features to develop?

PHIL [00:25:41] Interestingly, because this is a new area, there are no existing customers. So we did a few things. We used a lot of our own experience. We used a lot of experience of our investors. We picked our investors very carefully, actually, and we made sure that they were people placed in industry at the right point to be able to help us not just financially, but with a lot of expertise. And we sort of drew that together, did a lot of user experience design around it. And that really helped us to decide which features we wanted to implement, so then we implemented them. We then ran the beta programme and realised that we'd implemented totally the wrong set of features because actually what everyone wanted something else and they realised that actually you could do everything. So it meant that we had to go and build a load more features. An interesting thing was during the pandemic, we were just about to launch a particular type of thing just when covid hit. But as covid hit, of course, it meant everyone started doing a lot of remote working. We had a subtly different feature set designed for subtly different broadcast market, actually, and we very quickly pivoted at the start of the pandemic to focusing more on what people needed now. But while at the same time keeping an eye on the fact that hopefully the pandemic will end at some point and we're not going to end up with something specifically focused on being able to do lockdown programming. It's a difficult thing, actually trying to work out what features you want, because a lot of the time, if you say to someone, what do they want, they won't know or they'll just tell you what they've already got. I find it quite good to be able to sit there and gauge what is already out there, what people do, and then try and bring fresh approaches to it. And one of the fresh approaches that we did actually was take a different approach to the usability of it. If you're sitting in a truck, you have a big truck and there's lots of buttons and stuff. And one of the reasons that a truck is big is because it needs all that equipment in it and maybe all those people in it and things like that. But when you're in a different scenario, when you say doing the same job from your sofa with an iPad, you can do different things. You don't need necessarily physical buttons in the same way. And maybe some things that were a screen on an angle poise arm where you don't necessarily need that anymore. You can do it in other ways and made us really think hard about how our users in this new world of being remote or not necessarily in the same place as everyone else, how you might operate this stuff. And one of the things that I was really pleased about, actually, when we first started to take it out to real people, we gave it to veteran TV directors who just sat down and with about 10 seconds worth of tutorials, were cutting a show. Then we started giving it to people who weren't veteran TV directors and with a few seconds, they were starting to cut live shows as well. So I'm really pleased actually with the way the user experience went I'm really pleased with the way that all that has come together. I'm really pleased that people just sit down and use it. And that for me, cements that we've got it right. I think the most dangerous thing you can do is be a developer and develop the user experience. And that might even be you running a team of developers or you as a developer. So if you do your own user experience, you see it from your point of view. You've been thinking about it maybe for months or even years. If you bring your insular thought process to it, you will have something that you can use and nobody else can. And I think it's really important to try and get all those ideas and bring them together and just try it with lots of different people to produce the features in the way that people want them.

CHRIS [00:29:07] Finally, if we're going to give anyone keen to build their own app, one or two tips, what pearls of wisdom from your own experience can you share with us?

PHIL [00:29:15] Firstly, that people make a mistake thinking that they can do a big project with one developer. You know, even if you get a full stack developer, they only know one type of stack. Getting the right development team is quite important. And another thing that I think we should be a little bit mindful of is getting a student doing it free is not the answer. Even if a student turns up and says, I'll do it for 900 pounds, I've literally never seen 900 pound in my life. I'll do six months work from nine hundred pounds. You will waste the 900 pounds, you'll kill the student. They won't get a degree. It will be horrible. And everyone will hate everyone.

CHRIS [00:29:46] Phil Watton, founder of Mavis, a mobile production studio app. Thank you for listening. And if you'd like a cheat sheet for this episode, please go to . In the next episode, we'll be talking about how to launch and market your app.

Speaker 3 [00:30:07] OK, so there's a lot that I can be doing to build my audience and help this launch be as successful as it possibly could be. So people talk about optimising your app for the App Store. What do they mean by this?

CHRIS [00:30:22] This has been a fresh air production for the University of Sussex.

Episode 3 - Where's the funding coming from?

Essentials to include in your pitch deck, finding a technical co-founder, commercial sponsorship, seeking out investment and more. Chris O’Hare in discussion with Ian Wakeman from the University of Sussex, founder of TribeHive about his experiences of securing funding and investment.

Subscribe now!

Spotify podcasts badge Google podcasts badge Apple podcasts logo

Also available on Deezer, Stitcher, Amazon,, JioSaavan and Gaana

Register now to get a cheatsheet for each episode!


Download Episode 3 transcript - Funding [DOCX 21.03KB] or read here in full:

Intro music GUITAR HOUSE - Josh Pan (YouTube Audio Library)

CHRIS [00:00:04] This podcast series is brought to you by the University of Sussex. If you're curious about what makes some apps successful and others not, this series gives you a valuable insight into seeing if your app has got what it takes. With the help of three successful app, founders we'll be investigating and answering some of your questions. I'm Chris O'Hare, your host and resident app expert with 10 years' experience in software development and founder of award-winning technology consultancy Hare Digital. We've built apps for businesses big and small. This is how to make an app.

CHRIS [00:00:45] In this episode, we'll be talking about how to get funding for your app. This is an important topic because without funding you're not going to get your app built. An app isn't the cheapest thing to build. First, it's a good idea to create a pitch deck that demonstrates all the key elements of your idea. Now, a pitch deck is essentially a PowerPoint presentation that describes your idea to others, see it as an appetiser to highlight all the main points of why someone should be interested. To make a good pitch deck. You're going to need the following slides. The value proposition slide, a short one line statement that tells people what it is you're attempting to do. A lot of people use major brands to describe their offering, something like we're the UBER of the construction industry. Next, you got the problem slide. This is where you describe the problem you're trying to solve. This needs to be quite compelling. Tell a story about how and why the problem exists or how you just stumbled across it. Get across how irritating it is to some people. Next is a target market and size of the opportunity slide. Now, what you need to do is talk about who are the people you're trying to solve the problem for, how many of them are there? How much do they already spend in this market already, try to identify the niches? Because if your target market is too broad, it's unlikely you'll be able to reach it with marketing. The solution slide. Now, this is where you talk about your solution to the problem. How does your app fix your customers pains? Perhaps you can include a brief video or if you're presenting in person a live demo of how the app works with one of your prototypes that you've already built. The business model slide. How does the business make money? How are you going to differentiate from your competitors? Are you a premium or budget offering? Next, we have the traction and validation slide. Have you already had sales or a letter of intent from a major customer? Or maybe you've had thousands of sign ups on your website. You could also include testimonials of people have used your prototypes and if you already hit milestones, show how far you've got. What you're trying to do here is de risk the venture to potential investors by demonstrating that the idea has been validated. The marketing and sales strategy slide, how will you be seen by your ideal customers? What will make them take notice of you? Now marketing is quite expensive, so you need to be smart in how you approach it. You could even look at using guerilla marketing techniques to stand out. Now, this is one of the most important parts of a Start-Up and therefore should be treated as one of the most important parts of your pitch deck, along with the problem and solutions slides. Next, is a team slide, do you have the right team members in place to get where you need to be, what's their skill set and their backgrounds? Have they done anything like this before? And do they have a proven track record? Make sure to highlight all your team's previous successes. The financial slide. This demonstrates that you have a good grasp of your financial figures and what your Start-Up needs to fulfil your vision. You need to show your estimated revenues, your profits and your costs for the next three years. You're estimated at bill costs need to go in here too, and be sure to be able to justify these estimations if you've had quotes or you've modelled these against competitors. The competition side, now, more than likely you have competitors and it's not necessarily a disadvantage as it could help prove that your ideal customer has a problem in this area and is willing to pay to solve it. Explain how you are different from this competition and why your customers would use your service over theirs. What's your unfair advantage? The investment slide. How much investment are you looking for and how would you use it? What's the justification for this sum of money? You're going to need to understand your startup's valuation. The exit strategy slide. Your investors would like to see a sizeable return on their investment, but to do that, they'll need to see who your likely acquirers would be and if any other similar acquisitions have happened in the past, or you can even perhaps float on the stock exchange if you're very successful. That's a fundamental breakdown of how to create a pitch deck. It should be enticing enough to warrant someone to take a further look at your business, and that's probably when you'll need to have a more detailed business plan ready to go. And once you come up with your pitch deck, you then need to think about the different routes to get the funding you need to build your app and you can always fund the development yourself, although this won't be cheap, I haven't really seen a successful app out there has been built by developers for less than thirty thousand pounds. I wouldn't recommend borrowing to fund something as precarious as an app as you've no idea how successful it's going to be and you need time to fully mature the product market fit. Time is something a bank will not give you. Most people consider getting a technical co-founder and this is actually harder than it may first appear, although if you strike it lucky, the benefit is that you can get someone to build your app with as much passion as you and you've got a technical advisor to boot. If this is a route you want to explore, then the next step is to go and find a technical co-founder. I'd recommend posting on places that they'd visit or via a local developer, networking groups. You can also speak to developers to see if they know anyone who might be interested, although it can be quite difficult to pull a developer away from their own jobs and projects. And they will need to be suitably convinced that you have a great idea. They're in high demand and everyone says to them they have the next big idea. You'll also need to ensure that you have contractual obligations so if you have any differing opinions later down the line, this can be dealt with amicably. Make sure to set our expectations, goals and roles of each of the founders. Commercial sponsorship from a trading business is a very valid option to get funding too. Businesses, want a competitive edge and see speculative research led ideas borne from universities as a way to get a jump on their rivals, if not just a good marketing angle, although they may limit the growth of the idea to only be used within their own business. So, set expectations from the outset, I've seen many successful ideas grow this way as ultimately your working hand in hand with your ideal customer. Remember to make clear what you're bringing to the table. To set about this contact businesses in your field of expertise that you think would be interested in working with you or seek them out in conferences and get the contact details of a senior manager in the company. But probably the most common routes to funding yet appearing the most elusive, is applying for grants and government loans and there are lots of opportunities, but don't expect to get them without putting in the effort to meet their exacting criteria. These applications could take a very long time and there will be lots of people applying for the same funding. Innovate UK is the most popular grant opportunity, which is funded by the government and Innovate UK puts specific project proposals that businesses who are in this sector can apply for to receive funding. Although notoriously competitive and difficult to win, it can be a very effective funding route as they can be very sizeable grants. The best way to find out about the various grants is to contact your local enterprise partnership, as they'll have the knowledge about all the latest grant opportunities, but they also have their own grant funds available. Another option not to be discounted is the fact there are lots of entrepreneurial competitions which can offer a significant prize fund and media exposure. They're definitely worth entering and don't take much time after you've done the first application. The most glamorous option is to seek investment from an investor, though this often has many hoops to jump through and expect your idea to be thoroughly tested by shrewd business people. Your pitch deck has to be compelling to even be considered investable. Investors are looking for a heavy focus on commercialisation, route to profit and a return on their investment. The process typically takes a while for all the due diligence to be done. And bear in mind that you're taking on a shareholder in your business, which means that they often have a say on how things are done but equally, they can be an important ally with lots of connections and wisdom. Remember, investors want to get the best deal for them and they will look to take a healthy chunk of equity in your business so look to get offers from several investors to truly understand your worth. It's also worth noting that when you accept an offer of investment, you're going to need all the relevant legal documents drawn up. Now, the most likely investors will be interested in your business will be angel investors who are high net worth individuals, but there are other types of investors, including venture capitalists and private equity firms. Accelerators and investment brokers will be a good option to help you navigate through this process. There is also the Seed Enterprise Investment Scheme, otherwise known as SEIS, that is the government tax relief incentive that most angel investors use to reduce the income tax liability by 50 percent. But before investors can use this, the business needs to be SEIS registered, so make sure you do that. There's no right or wrong way to get investment, and often you can combine several different ways to get the money you need. We catch up with Ian Wakeman again to discuss how he went through the various funding rounds, including receiving grants and investment before passing the CEO role to an angel investor called Aidan Cooney. Thank you, Ian for joining us again. I want to get your opinion on funding and the various stages that you went through and any advice that you would give to fellow either academics or entrepreneurs out there that would like to kind of go through this journey. But let's start off with working out exactly the different types of funding you received, how much you got, and kind of what was the influence of getting that funding.

IAN [00:11:40] Nice to be here again. I've been an academic for 31 years now and I'm doing computer networks. And obviously there's always been a fair amount of sort of commercial activity taking things which academics do as commercial networks and turning them into companies. To date, I've never really found something which really attracted my interest is something that should be commercialised. So, once we got the money to actually run the initial projects with Brighton Hove Albion when we got to the end of it, the club was keen for us to commercialise it. The football league was keen for us to commercialise it. And talking to the team, we felt happy that this was the right thing to do, to actually turn ourselves into a company and see how we can actually sort of make it work as a commercial activity. So, the interesting thing is around academics, there is a structure of funding that allows people to take a potentially commercial ideas into the commercial world. Obviously Innovate UK itself, sort of would supply money for Start-Up funds for certain businesses because of the timetable we were working with, another deadline came up and Royal Academy of Engineering was running these Enterprise Fellowship schemes where they'd give 85,000 pounds to sort of people to help them commercialise an idea, give them coaching, support them and get them to the point where they could launch a company with their product. So, I put the application into that and found out sometime in November of 2013 that we were awarded that. So, we were then able to, with a fair amount of confidence, spend the next year building our software, testing, making sure it got better and better so that we could actually sort of deliver workable products and get sales in. The main source of funding for any company should always be sales for instance, so we were absolutely delighted in February 2014 when we actually got our first sale and got a commitment from the football league that they would run a sort of test trial with clubs over the course of the 2014-15 season with our software. And we worked with six clubs with Brighton obviously but also with Crystal Palace, QPR, Bolton, Birmingham to sort of build apps for them. That was great. That was a source of funding and that would enable us to actually get into the position because we impress them enough with ourselves that we could actually sort of turn ourselves on, hire to full time employees and pay ourselves wages. So, we actually had enough money coming in from our initial customers to actually sort of fund ourselves going forward. Now, you'd like to think that was all you needed to do. Business to business the clubs were saying, yeah, this is really good. And yeah, we like the fact you've created the football league player and funding. Problem being as February 2015 turned around, the clubs were saying, yeah, this is very nice, but we'd like to reduce our costs. So, they sort of forced us to sort of reduce their monthly fee. And so, we're starting to get a bit sort of dodgy about whether we can keep paying ourselves salaries. And that point we started looking around to see what we can do about Angel investors. I spent a lot of time going around various angel investor groups, talking through various people about sort of what we need to do, things to be aware about. Once you take your angel investor, you've got to be fairly sensible about contracts in terms of the agreement are going to be the investor wants the best terms for them. You want the best terms for yourself. And you've got to make sure that you come to an agreement without getting lawyers too much involved, because otherwise they spend an awful lot of money on sort of lawyer costs, which eats up a chunk of the capital that's coming in. We made that mistake. We didn't make it again. We did a lot of work with VCs. We went to various venture capital groups talking to them. We had offers on the table from one group to invest. They were willing to put in sort of £120k in for us. But then we also had angel investors starting to get interested and said the key one for us was Aidan Cooney, who did run Opta, knew what the business was, had a lot of contacts. So, he was able to leverage us up to actually sort of be more active in these sort of sporting arena that gives more credibility as well. So, we took that investment and we were able to sort of move forward in 2015 to the point where sort of we made the transition from ourselves being run by myself as a chief executive officer to being an Aidan in to actually sort of start running the company. Once his sort of non-competing period was over. Aidan was a lot more credible. And again, because it builds Opta from a small company that is statistics to sort of something that was worth £54 million, which performed group at the time, then took on and bought basically a lot of credibility with sort of investment groups and was able to bring in a much larger sort of seed funding than we ourselves would ever be able to do. And so we got 1.2 million in December 2015 to support the group going forward. So we were able to bring in more hires and start to pivot around sort of what we were doing in terms of products as well. And that was the point I left to return to the university.

CHRIS [00:16:30] Out of interest. What's the breakdown of the money you received to make all of this happen?

IAN [00:16:35] You know, initial research project within university. We got the money in October 2012, which funded us through the first year as a research project. That was 80,000 or so then we received the Royal Academy of Engineering Money, which actually technically came in February 2014 as £85k to again support us. I already had agreement and we notified about November that that money was coming. I was being sort of bought out to be paid by the university. And we were able to support the other people actually in the company at that point because there were still just the three of us. John was working part time Keiran Tently was a PhD student and being funded on a funded studentship. So we were able to look after ourselves in the period between September through to February 2014. We got our first sale in February 2014 to actually sort of build and put in place the apps for the first six clubs and obviously the 85,000 came in, which 40,000 was basically for us to actually sort of manage as we wish. Another 40 grand went to the university to pay for my replacement. So, I still funded being paid by the university in the 2014 to February 2015. We then took investment in April 1st or April 2nd or something, 2015 from Aidan, which was 120,000 and then sort of Aidan brought in the sort of second round, the seed funding one point two million in December 2015. One of the scary things about running a company is always worrying about whether you can pay salaries at the end. It was difficult sort of looking at the business accounts and looking how far overdrawn we were getting each month just because we were just on the brink, actually, where we make making a loss, basically. So, the salaries were going out and we were creeping further and further into the overdraft then the fees would come in from the football league make us look a little bit better. But still, that didn't quite cover our costs and our costs rose. And it's not just the salaries. We also had sort of cost around sort of running the AWS service as well. Again, we cheated, we did use academic sort of credits for AWS for a while, but then they ran out and we had to start paying proper fees where all of a sudden we're paying over a thousand pounds a month for AWS, there's an unexploited market there around what you do with all the information people are happy to give a football club even in the light of GDPR. What can you do with that information to increase the amount of money you make per fan? And that's essentially what the proposition was that sort of attracted investors and we built up to sort of getting a new round of investment of basic seed money in excess of one million pounds. At that point, I left to go back to university in January 2016, and Aidan has taken the company forward from then.

CHRIS [00:19:18] Ian Wakeman, co-founder of Tribe Hive, thank you for listening. And if you'd like a cheat sheet for this episode, please go to In the next episode we'll be talking about how to build your app.

TEASER [00:19:37] If you ever see a live show being made, maybe the football ground or say a theatre, you'll notice some big trucks in the car park and these big trucks are full of equipment, full of people making the show. They've got lots of cables coming in out of them. And what we've done is we've taken all of the equipment in those trucks and we've put it in the cloud. This means you don't need to have those trucks. All the people that would have traditionally driven to the car park no longer have to do that. They just connect to the cloud from home. And in our case, they use a suite of apps to then control the cloud based virtualised equipment.

CHRIS [00:20:13] This has been a Fresh Air Production for the University of Sussex.

Episode 2 - What's an MVP and why do I need one?

What’s an MVP and why do I need one? How do you decide on your App features? Chris O’Hare in discussion with Ian Wakeman from the University of Sussex, founder of TribeHive about his experiences of developing an MVP and testing it.

Subscribe now!

Spotify podcasts badge Google podcasts badge Apple podcasts logo

Also available on Deezer, Stitcher, Amazon,, JioSaavan and Gaana

Register now to get a cheatsheet for each episode!


Download Episode 2 transcript - What's an MVP and why do I need one? [DOCX 27.34KB] or read here in full:

Intro music GUITAR HOUSE - Josh Pan (YouTube Audio Library)

CHRIS [00:00:04] This podcast series is brought to you by the University of Sussex. If you're curious about what makes some app successful and others not, this series gives you a valuable insight into seeing if your app has got what it takes. With the help of three successful app founders we’ll be investigating and answering some of your questions. I'm Chris O'Hare, your host and resident app expert with 10 years’ experience in software development, and founder of award-winning technology consultancy, Hare Digital. We've apps for businesses big and small. This is How to make an app.

CHRIS [00:00:45] In this episode, we'll be talking about defining and designing your minimum viable product, ready to give to a developer to build, and in this stage, we want to take all the feedback that we've learnt from the previous episode: the testing, the prototypes, the website pages and turn it into an MVP. Now MVP stands for minimum viable product. Eric Ries, author of the book ‘Lean Start-Up’, coined the term where he described it as a product that is used to collect the maximum amount of learning with the least amount of effort. An MVP is usually released to market as quickly as possible to test an idea with real users before committing fully and also learning what resonates with the ideal customer. Now, this doesn't mean it has to look bad or you can't charge for it. What it means is that the product needs to solve the problem that you're trying to solve so you can then confirm it's a problem out there in the real world. To start with, we need to understand all of the features you'd like your app to have, and you could do this by creating a big list which can be separated under different user roles. So, for simplicity, say if we have a list for customers and a list for administrators, and then under the customer column we can talk about all the features that customer would like to do, such as log into the app with an email and password or receive an email welcoming them, see the dashboard with their latest stats, go into an account and change your email address - all those kind of features. And then under the administrator column, we have features like disable the user account to stop them from logging in or changing a customer's subscription manually, or even adding a new administrator. Now, what you're doing in these columns is describing the actions that the user typically takes. In ‘scrum project management’ these are usually called user stories. Now, for each column, we then do a MoSCoW analysis. And MoSCoW is a project management tool that enables you to determine the priority of each one of these features. And it comprises of the following four sections. So, you've got must have, which is non-negotiable features that have to be in the app, and then you've got should have, which is the important features that add significant value but can be left out. You've got could have, which are the nice to have features that add some value and you won't have, which are not important at this moment in time. To understand the priority for each of these, you can take the feedback from the validation and the prototyping stage and start to discern what features go in what section and ask yourself what did the users always comment on? What did they feel strongly about? And once you split out the features, what's not in the first two sections, should go on the backlog for later. Now, we're determining what should be part of your MVP and if you find this hard to do then what if I told you that every feature will cost money and that your ideal customer may not even care about it. It would feel like a waste of money, wouldn't it? So, we want to prioritise what your customer must have in order for them to hand over the cash. And there's actually a neat trick at this stage to save money. Your app may not have a lot of users at the beginning. Therefore, what you could do is you can fake clever functionality, especially if it costs a lot of money to create an algorithm or something similar. You can create a user interface that sends off to a real-life human who will work out the problem and input the result manually from the administrator side. Once this is unmanageable, you could just outsource this to someone else. And don't be surprised that a lot of start-ups saying they have artificial intelligence, actually have a lot of human intervention. So now you've prioritised your list of features. What next? Well, you're going to need to work with a UI UX designer to create a specification to be able to pass over to a developer. A user interface and user experience designer is an expert in modelling how the app should work, along with all the intricacies of each button and how the final design should look and all the animations it should do. Often a UI designer and a UX designer is the same person as the job roles tend to overlap quite a bit. The designer will have a lot of experience in mapping out human behaviours and where users would expect to find a button or actions that take place. Given the app an intuitive feel, which is really important if you want the users to keep coming back. Designers are often found in the prototype stage as well as they often conduct user research, user testing, user personas, and they make wire frames too. But finding a UX and UI designer should be relatively straightforward, and if you're already speaking to an agency they'll always have them in their team, or they can recommend someone likewise with a freelance developer. So, make sure to check out their portfolio as every designer tends to have a different style. So now you've got a UI, UX designer, what you need to do is finalise all the wire frames that you did in the prototype stage with all the feedback that you've gathered. But this time you're going to add Wireflows. Wireflows are wire frame screens with flow lines showing what each feature does and a description of how it should behave. And does it go to a new screen or does it show a pop-up message? What happens when you cancel it? These are the kind of things you'll see next to a wireflow. Now, wireflows can either be a big map showing all of the wireframe screens with flow lines between them, or they can be broken down into feature specific wireflows. And you may need to do several diagrams of the same screen to fully describe what it does if it has a lot of functionality. You'll also need to create a mood board, which is a collection of examples, screenshots, colours, design elements and even competitors to help the designer fully understand what you're visualising. Remember, they're not mind readers. Sometimes it's also best experts crack on with the design. There's a lot of Back-Seat designers who think they know better than the expert. The designer will take all of this information that you've given them and turn that into a detailed design specification, along with all the design assets the developer will need. Some advice around this stage is to ensure the design specification is clearly articulated and as detailed as possible. No grey area that's open to interpretation. For example, if you want the app to send out pretty emails, make sure that's in the documentation. Essentially, what you're doing is reducing the amount of time a developer has to think. The more they think, the more time they will take and ultimately it will cost more. So earlier on, I caught up with Ian Wakeman, co-founder of Tribe Hive, a sports stadium companion app, to hear about his experience of building an MVP.

IAN [00:08:06] The story probably started in 2011 when the stadium was completed for Brighton Hove Albion, the Amex community stadium. One of the things about having this great big thing planted like a big spaceship next to us on the other side of the A27, Brighton Hove Albion realised there's going to be a level of disruption to sort of both University of Brighton and University Sussex in match days. And so, they were keen to build good relationships. So, we set up a meeting between the club, Brighton Hove Albion and various representatives - between American Express and number of their representatives and people from the University of Brighton and University of Sussex to talk about possible collaborations and in particular things we might do around the research space. There were a number of things that sort of kicked around. I got rather excited seeing that they were actually keen to do something about this because I'd had something kicking around for quite some time about how to make things work better in crowds. I'm a big football fan. I've spent my life most of the time following Chelsea, going to sort of Sweden and going to all sorts of strange places to watch them. I've got a season ticket with Brighton when the stadium opened because my son was a big fan and problem about football matches you’re in a crowd of about 30,000 people. And when you pick up your smartphone and try and use it, you find you can't get a connection out of the crowd because you've got 30,000 or more people all trying to use the 3G base station capacity to actually get their connections. So, because at the time, both Android and the iOS operating system in Apple were starting to build towards allowing sort of nice interfaces into their devices. I started to think, well, okay, there's a way of actually possibly making this work, looking to see how you can get phones to talk to each other in a crowd and circulate the data around between the crowds on a phone to phone basis, so you're next to someone, they've got a phone build, a connection between those two phones. And a thing about sort of capacity of 3G base stations is whilst you may not be able to get a connection, there are still around 200 people in the crowd who can use the connection at that particular time. And the idea was once you get to a stadium, your phone would build a connection with all the other people running the same app in the crowd. You wouldn't have the data, but once you can connect, would reach out back to sort of the servers and sunk down the updates to the app and circulate around the phone to phone network within the stadium. So that's the key bit of sort of technology testing we wanted to do. EPSRC, the Engineering Physical Research Council is the normal body I go to for research funding. So I sort of had some basic sort of conversations with the club about how we might sort of fund this. And so, I went and put an application in to the council asking for what was about 80,000 pounds or so to actually do a one-year project to see if we can actually get this phone to phone network running within a crowd within the football stadium. It was funded. And so, at the start of 2012, we had money and I pulled in the team, who were going to sort of build the software, who were going to do the testing. And we started on the research project to see if we could get this phone to phone connection in the crowd working.

CHRIS [00:11:18] So who else was on board to help you?

IAN [00:11:20] We had a great deal of help from the club, in particular from Paul Camillin, who is the sort of club publicity officer. He said, okay, this is great. Let's go and see if we can make it work. It would allow us to connect with a number of season ticket holders who would act as our user base and we would then sort of build an app that made sense for those fans, so we had two lines of work. We had basically the technical work, working to build the library which would make the phones connect to each other, and then we also doing some work around the user interface to make it an app which actually people wanted to use. So, we worked with the fans ran focus groups, ran surveys, and sort of built sort of mock ups and then sort of built into sort of high precision sort of prototypes to test whether this was something a fan might like. So, on the way through the 2012 2013 season, we came up with a pretty good design of an app. As we drew closer to the end of the season in sort of March, we actually got the software working for the first time after several sessions where our technical team would spend an awful lot of time overnight working in deed there was a of a couple of occasions where they did an overnight stint on the Friday night to be able to deploy out to the fans on the Saturday morning so they could test it out on the last few matches of the season in April of 2013. And the great thing about this was it worked. We got the software running. We had all the test results came in. We could see that it was actually more efficient. We could see standing in the crowd that we were getting sort of better connections than you could get off the BBC site with Sky Sports. And so, we knew we had something which actually worked and the club were really enthusiastic about it. They saw what we'd actually built. They'd seen we'd actually had an app which was sort of best of breed around the championship clubs at the time. They'd seen that the technology did what it said on the tin. It made a better connection out for the sort of the app itself. So, they were keen to actually for us to make it into a commercial product, we had a basic minimum viable product then, there were a lot of problems with it. There was a lot of work to do to actually sort of clean up the code, make it work and get it ready for something that would actually be allowed by the Android and play store. And then later that summer in 2013, something that will be allowed by sort of Apple onto the App Store.

CHRIS [00:13:35] So I guess the thing was, could you really make this work? And what was that like?

IAN [00:13:40] One of the interesting things about sports is the actual rights of who can do things with scores, with the club colours, with badges and all those things which copyrightable, tend to be owned not necessarily directly by the clubs and in particular the digital rights of all the clubs which were in the championship and League one and League two were owned directly by the English Football League. So, we had a number of conversations with the EFL over the course of the project itself to make sure they were happy with what we were doing, again facilitated by sort of Brighton Hove Albion. First time we met them, they went AH! this is so crazy it might actually work. So, we were feeling quite encouraged. And so, they were looking at us and this was reasonable. Summer of 2013, we said, yeah, OK, we're going to develop this into a commercial product. Are you actually interested? And they said, yeah, get getting to the point where it is a proper commercial and MVP and then we'll support you. Coming towards the end of summer, something which we thought was going to be viable properly. We did need at that point to think about, well, what can we do? How can we get the funding to actually support its next sort of step? This is the point where it's really useful to actually be in a university. There are many pots of money around for commercialisation of university research. In particular, the one which came up and, just because the deadline was appropriate for us in sort of mid-September, there was an opportunity to work with the Royal Academy of Engineering to become what they call an enterprise fellow, which basically meant you got 85,000 pounds and remember, we had another £80,000 pounds previously to actually do the initial sort of build, which was sort of, by all my time out of teaching as it turned up and without some support for sort of bringing people in and paying them to allow us to actually sort of move forward with the product. Our team and I sort of made the commitments in September to actually sort of form the company and try and go forward if we were to get the money, we would have to think about how we can get other funding if the money didn't come through. We called it Tribe Hive after much kicking around with partners and everyone else because picking the right name for company once you've got some technology feels as though it's an important thing to do. One of our team actually got some artistic creative talent, came up with a pretty good logo, the only thing we didn't have at that point was customers, which is kind of a difficult thing for a company to be in. Nonetheless, we persevered trying to sort of get our products up to a commercial standard. We got the EFL down sometime in December 2013 to come have a look, see what we were doing, go and check to see how it worked and did what it says on the tin. They were happy with it. Then we got the go ahead in February to say, yep, we think this is good enough. We're going to use it and roll it out to a number of other football clubs who are going to volunteer to do this and will pay you some money. So, we got our first £20,000 pounds in from the EFL to roll out prototypes for six clubs. So, we built these apps February through to sort of June, showed them to the clubs and we were ready to go and rollout for the start of the next season.

CHRIS [00:16:46] Of course, you need to fly the flag about all this to tell people that you've arrived. And how did that go?

IAN [00:16:52] We did a launch event with the Royal Academy of Engineering. They were quite happy the fact that sort of we’d already to turned the product into a company that was already making money. So we had a really nice a launch event down in London at the Royal Academy of Engineering's headquarters. And we were nervously biting our fingernails about what would happen when we actually launched in August, when the football season started again and it worked. Again, it just was nice, we did an awful lot of work, we did a lot of testing. We launched again on Apple as well, we mapped and brought in sort of a couple of people in March, our first two proper employees to work, and we had an Apple version built as well. We had two versions of the app for each of the clubs, so 12 apps in total on the play store and on the App Store, and the fans liked it. These were the first sort of apps for sort of championship clubs they downloaded. And we had sort of a very quickly nearly 100,000 uses the week going forward.

CHRIS [00:17:49] How do you then monetise all of this?

IAN [00:17:52] Once the clubs were happy, we would negotiate a monthly fee to actually keep the apps running to run the updates. This wasn't necessarily so sort of popular. I mean, the clubs aren't very rich when they're in the championship. The vast majority of their money goes on player wages. Putting infrastructure around to support fans is expensive and doesn't necessarily bring the sort of return on investment that they would like. So, we looked around and fished around and talked to sort of the customers to find out what were their problems. It turned out one of the big problems was there was a way of sort of getting broadcast of a football match when you weren't actually there at the stadium. And it was built in as a digital player thing that was played over the Web. The football league did have a generic app and the company that produced that were asked if they could incorporate the football league player into their app and they just couldn't do it because there was a little bit trickiness about the source and what their codings were. We looked at this problem and went yeah, we can do this. So again, we spent some time writing software, we said we can pitch this to the football league saying we can do this. And they agreed another 15,000 pounds if we get it done, demonstrate it was working and rolled it out to the apps, so we did. And so now we basically had another chunk of capital come in. We had the monthly fees of around six thousand pounds coming in. So, we actually feeling like a proper company. Five of us working to actually build this software and we were starting to make progress and starting to actually sort of feel as though we were going forward. We got the opportunity from the football league to go and approach other football clubs. So again, we looked at all the other championship clubs. And I must confess, I'd been doing an awful lot of time on the phone doing the business development. I could ring up sort of just about any club for memory, for that telephone number to go and talk to their publicity officer or their commercial officer to try and get a meeting, to try and put together what we were doing. Again, because we were giving them a solution to a problem that their fans were telling them about. It was relatively easy to get in and have those conversations beyond the original six, we've got to Cardiff, Nottingham Forest very quickly we built up to ten clubs by February 2015. At that point, it got a bit interesting. The clubs themselves, they said, well, a thousand pounds is too much, we need to reduce that. So, we got down to 800 pounds. So now we're getting 6,400 in a month. It's getting difficult to actually pay everyone's salaries and we wanted to expand as well. Around that same time, the person who used to run Opta, Aidan Cooney, rang me up and arranged to come and have a chat because he was looking for a new CTO for his own new company. So, I went and had the chat. We actually turned the conversation around to sort of rather than him sort of poaching me, he actually wanted to get invested in our company and go for it. So, at that point, we had our first angel investor coming in to actually inject some money to allow us to grow and to move forward. And that deal was finished in these 2014 when we actually sort of sealed the deal. We got a hundred twenty grand in and we started to move forward to bring in more people. We worked with Aidan to actually build better sort of relationship and actually understand what he thought you could do with the market. And again, we spent a lot of time talking to the clubs. We went to the major football exhibition. We basically did an awful lot of work to do sales to actually sort of form relationships, sell to expand out to sort of Premier League clubs as well. So eventually we got to Aston Villa, which was a really good sign. We had Crystal Palace as well, and we're feeling quite a good place. 2015, we were growing. We brought in new employees. We'd moved out of the university into proper premises, and we were sort of working to actually build relationships not just with football clubs, but starting to work with other clubs as well, we spent time working with the rugby league, talking to rugby union, the rugby union Premiere League and with the 12 clubs who were over in Ireland and it was looking to be going forward relatively smoothly, obviously you always want more customers. And then I got the offer to return back to the university. They want to be back and sort of run the department, and I had to make the difficult choice about what I want to do.

CHRIS [00:21:53] Yes, I can imagine this was a big moment for you. So, what did you do?

IAN [00:21:57] I eventually sort of let it go, Aidan wanted to come in and actually sort of run the company. Sold Opta for somewhere in excess of 50 million pounds, you had a bunch of investors who were quite happy about him and they were very keen for him to come in and build a new sports marketing company that will not just use our technology, but would also look to build digital management systems for football clubs. And now the company builds apps for multiple sports. It works in cricket, in both rugby union and rugby league. It runs a very successful Super League for membership management system. It now works with Sky Sports. They now build, manage the Sky Sports, score up and everything seems to be going forward and actually sort of building the technology and the machine learning mechanisms in the data science, things that actually tell you about what the analytics are around the fans themselves. Everything was going smoothly and then the pandemic. The company is in a strong place to come out of this. Now, more than ever, clubs recognise the importance of digital.

CHRIS [00:22:59] How did you turn that idea into a prototype? The conceptualisation of what it is that you were going to do and then say, right, this is how we're going to do it? What was the process of that?

IAN [00:23:10] Once we had the money and we were looking at how to do the plan of how the project was going to work through the first season, we knew we basically had to have both an app which engaged fans which fans wanting to have on their phones. And we needed to build the technology itself, which would allow the phones to connect to each other, to then sort of be able to distribute the data in the phone to phone network. My colleague, John Rimmer, we basically sat down and we worked together to come up with what's going to be a way of capturing the user journey so we can actually give them what they want on the app. And that was based around a number of things we did I mean John's got a strong background in ethnography. Remember, of course, that we actually sort of worked with the club. They gave us access to sort of 100 fans or people who wanted to opt in and work with us to actually build this app. So we had a user base that was a) committed to the club and b) were enthusiastic about technology. We ran a couple of focus groups to allow us to actually get a handle on what they actually wanted as the features within the app. So we put up low priced mock ups of sort of things we want to do tables, scores, commentaries, all the things you can actually get around sort of a particular match. They also wanted the ability to actually sort of send communications. We looked at how we can actually do things like Twitter, Twitter turns out to be relatively easy. And so we had an initial set of features, John then also set up a survey. So we actually went wider to number of fans saying, what do you actually want in an app? So, again, we had sort of a quantification about sort of what things were most important. We also did ethnographic studies. John met people in New Haven and went with them on their journey into the stadium, collecting, understanding and evidence about what their journey is, how they meet people beforehand. Actually, a family event, sort of father and son. We had a lot of time for every match in the stadium. So basically in the sort of 2012, 2013 season, the club were generous enough to give us access to the West Stand, so we were able to go into the stand, talked to the fans, engage them, get them to understand what we were trying to do, and we were able to observe what fan behavior actually was, and again, it's fairly obvious if you go to football matches, there's a lot of fans who go to the pub and then get the train and come to the football stadium. Then there were mill around using the bars in the stadium to have an extra point or two and then go in to watch a football match. And then some of them would come out and try and get another pint in half time. Brighton football ground is relatively remote, a lot of people who actually hung around after the match. So, given that journey understanding, given the way we actually sort of knew the fans worked and given the conversations we had with fans, we knew what the right features we should have on the phone should be. We then worked incredibly hard. We recruited in PhD students, incredibly sort of talented. Kieran Fisher is still the CTO of the company now. Steve Naicken now lecturing, and we built the software that made everything work, and again, the amount of effort, the push we actually did to make this work because we knew we had something that was going to be potentially be really exciting, was incredible. We did an awful lot of logging and sort of capturing of data about sort of how much were being communicated, how much was being moved around by the phones between the stadium so that you could write the paper, and we sort of we wrote a paper over the summer that we got published which demonstrated the prototype working, but it was a research prototype. It was something that was a bit crufty in some areas, which we had to work a little bit to actually get onto the main app store, this is all distributed via the testing channels to begin with, so we have to do quite a lot of work to get it up to sort of the standards play store would really accept. And we also needed an iOS version. We need to actually sort of create an Apple version. So, we did a lot of work over the summer to actually put together a version that could be put onto the play store for Google and put onto the App Store for Apple so that people could actually put it in their phones. And so, by the time August came around for Brighton Hove Albion, we had something which looked like a good minimum viable product. Brighton Hove Albion got permission from the club to actually sort of go wider than the initial test group. And so, in 2013, we launched a minimum viable product that went out to every fan within the stadium at Brighton Hove Albion. And that gave us a lot more information, a lot more feedback where we could actually fix the bugs, fix the features very quickly, introduce new features as people wanted them, and get to the point where we said something which we thought was commercially viable.

CHRIS [00:27:33] What did it look like from the prototype to the commercial version, from this rudimentary app to the polished version?

IAN [00:27:40] As anyone will know, once you actually get started in and start to be built, things which actually makes sense within the operating system, both iOS and Android, it can get quite crufty quite quickly. So, a lot of the effort was actually cleaning that up, making sure we had clean structures so we could do maintenance on the code and actually we were just basically improving the efficiency of the algorithm. It was just incremental sort of fortnightly on fortnight off sort of improvement using the sort of the data we got back from our logging. Again, we're talking in 2013, Apple and Android weren't as strict as they now are on sort of where you could get on there. We were doing things which were a little bit naughty. One of the things which stopped people doing this before in Android was basically you're not meant to do it. But we found some little tweaks you could do around some of the interfaces which allowed us to plug in when we shouldn't be, to actually sort of run what was Wi-Fi direct, when normally it requires a user to sort of say, yes, this app can sort of turn on Wi-Fi, direct. Anyone installing on the phone that we make sure they're aware that when they got to the football match, these things would turn on and only then. So, we work on the privacy notice and sort of making fans aware of what they were getting. We felt ethically right, now we tried that. I think we'd actually sort of have real trouble getting on either store.

CHRIS [00:28:56] The Hacks, as technology progressed on those mobile platforms, they became a lot easier to kind of utilise the actual proper way of doing things.

IAN [00:29:04] So the hacks became sort of integrated into sort libraries that were actually supplied by iOS and Android themselves. And the interesting thing is essentially, as Wi-Fi has improved, as the 3G 4G network has improved, it was turning out by 2015, 2016, it wasn't necessary anymore to actually sort of really sort of push the phone to phone connection. We'd done all the work. We made our reputation. Sometime around 2016, the company stopped developing the sort of phone to phone system because no one was asking for it anyone.

CHRIS [00:29:37] That's really interesting that you took a USP, a unique selling point, for this technology. This is basically open the doors for you. Once you've made the brand, once you made the name for yourself, that you then essentially could create a whole commercial entity around it.

IAN [00:29:52] Yeah, absolutely. I mean the point is what you want in the relationship between a company that does sort of does business to business services is a company that solves problems. So, we started by solving the problem of connectivity within a stadium of providing an app that fans wanted to use. That was a problem perceived by the clubs. They're aware of it. Then we sort of solved the problem of providing these sort of the football league player on an app. Again, everyone was happy. This kept the clubs interested, kept the clubs actually sort of using the apps, and then we just basically continued that sort of journey. I mean, we did a lot of work working with QPR and Ticketmaster to put together the app that enabled the phone itself to become your ticket. And that's the technology which is now sort of rolling out and becoming more widely used when Aidan took over to turn the company into a sports marketing company to look to actually sort of do this sort of data analysis and to actually build the fan journey and enable clubs to actually sort of get actionable data out of that, was also the pivot to actually solve the problem the clubs have. And this works really well in Super League, and it’s started to be rolled out in other areas as well.

CHRIS [00:30:58] Ian Wakeman, co-founder of Tribe Hive, thank you for listening. And if you'd like a cheat sheet for this episode, please go to
In the next episode, we'll be back with Ian talking about how to fund your app.

TEASER [00:31:19] There's an unexploited market there around what do you do with the information people are happy to give a football club even in the light of GDPR. What can you do with that information to increase the amount of money you make per fan? And that's essentially what the proposition was that sort of attracted investors, and we built up to sort of getting a new round of investment of basic seed money in excess of one million pounds, at that point I left to go back to university in January 2016, and Aidan has taken the company forward from then.

CHRIS [00:31:48] This has been a fresh air production for the University of Sussex.

Episode 1 - Is my idea any good and where do I start?

Is an App the right way forward? Where to get started, developing your idea, testing your idea and checking if there’s a market for it. Chris O’Hare in discussion with Georgina Smith.

Subscribe now!

Spotify podcasts badge Google podcasts badge Apple podcasts logo

Also available on Deezer, Stitcher, Amazon,, JioSaavan and Gaana


Download Episode 1 transcript - Is my idea any good and where do I start? [DOCX 20.88KB] or read here in full:

Intro music GUITAR HOUSE - Josh Pan (YouTube Audio Library)

CHRIS [00:00:05] This podcast series is brought to you by the University of Sussex, and is part of the university's knowledge exchange programmes. From fitness and finance to beauty and games, there are millions of apps out there and maybe you've got the next big idea for one. But where do you start? And if you're curious about what makes some Apps successful and others not, this six-part series gives you a valuable insight into seeing if your app has got what it takes. With the help of three successful App founders we’ll be investigating and answering some of your questions. I'm Chris O'Hare and I'm the resident app expert with 10 years’ experience in software development, and also founder of award-winning technology consultancy, Hare Digital. We've built apps for businesses big and small. This is ‘How to make an app’.

CHRIS [00:01:01] Apps usually refer to two things, a Web Application, which is a programme that works on an Internet browser and a mobile application which is on a mobile device. And most businesses need both, but for the sake of simplicity, we'll be concentrating on mobile apps in this series. But why should you build an app when there's around five million apps across the Apple App Store and the Google Play store? These are the two biggest mobile platforms. Well, ever since the dawn of the first iPhone in 2007 and the App Store in 2008, apps have become a way to provide functionality, in an entirely new way on a mobile device, a device that for the most part you have to hand, and that creates a big opportunity to interact with a user 24 hours a day. And that's the first reason why you should build an app. You're able to communicate with your user through push notifications. And what this does is nudges them to look at your app and incorporate it as part of the daily routine. But another reason is the ability to access some incredible technology and sensors that these phones have, and that enables the app developers to do some extraordinary things. Some might argue that the convenience of being able to have the app ready to use on your device and able to use the app offline. But I don't think this is much of an argument now as there is such a thing as app fatigue, where people don't use 62 percent of the apps on their phone if they average around 30 apps a month, and most people would default to using Google before using an app anyway. Before we get started, you need to ask yourself, why do you want an app? And you need to be very honest with yourself because it's not enough to just say I'll get downloads being on the App Store or because everyone else has an app. Can you do your idea without an app? And if you answer yes, then you should definitely start there. And if you also think about creating a sustainable business model, selling one off apps on the App Store, then the world has moved on and you need to think how many apps you've bought off the App Store and I bet it's not as many as you would think. So in this series will be focused on creating apps that you pay a monthly subscription to use. And if after all these questions you still want to build an app, then this podcast will help you navigate some of the hurdles in the process from conceptualising your idea, funding, getting a developer to build your app, marketing and then scaling your growth. You don't need to be technical at all, you just got to love solving problems. With me is Georgina from the University of Sussex, and Georgina is typical of many people who’ve thought about making an app but doesn't know where to start. And she's going to ask me the kind of questions a beginner would like to know. Hi, Georgina.

GEORGINA [00:03:49] Hi, Chris. Seriously interesting stuff so far. Thank you. So, if I had an idea, how would I get started?

CHRIS [00:03:58] So Georgina, to start building your app, I go through a process called ideation and validation to start forming your idea into something we can use, and ideation's about getting your ideas out of your mind and into the real world, and validation is about taking those ideas and seeing if they solve the problem. Firstly, ideation. Writing down what's in your head is incredibly insightful, it creates a structure to your idea and enables you to share and collaborate with someone, and some of the things you should write down include: what's the problem that you're trying to solve? How are you going to solve it? Are there any other ways to solve it? And how will you sell it and where will you sell it? Don't get too wrapped up on how this looks. You're just doing a brain dump of all the information that's in your head and you could do this on your own or as a group brainstorm as they may spark of other ideas. It's also quite useful to define the persona of your ideal user at this stage, you may know your user incredibly well, and if you don't, you definitely should. But the main reason for this is if you had to pass on the project to someone else and they needed to think like the ideal user, how would you describe that person to someone else?

GEORGINA [00:05:13] Okay, great. That's really interesting. So, I need to think about the problem that I'm going to be solving. I need to think about where I'm going to sell my app, who I'm going to sell my app to. So, can you say a little bit more, Chris, about that defining the customer persona, say how I should go about that and what kind of things I need to be thinking about?

CHRIS [00:05:33] Yes, a really good question Georgina. So, I like to use the audience of one methodology for my personas, and that's where you find real people in the real world. That would be your ideal customer and you can follow them on social media but the idea is that you really get into their mindset, and try and understand the demographics; their age and the location, their career, their family, but also the psychographics. So, what do they think like? What motivates them? What do they enjoy and put all of this into your ideal customer profile. And then when it comes to marketing later, you have a person that you can actually target. And if they buy your product, you know, you've nailed the persona.

GEORGINA [00:06:18] And I can use that information later as well to help me with my market research. So, how do I know if my idea is any good? Because I might have a million and one ideas, but they might not be any good. How do I know that? How can I test that?

CHRIS [00:06:34] Okay, so once you've done this, you kind of need to validate some of these hypotheses that you've come up with, and I break this down into the three C's of customer, company and competitor. And the first one we need to talk about is your ideal customer, and we need to talk to them and we need to do that in as many ways as possible. And some ways include creating surveys, calling them up, interviewing them, invite them to a focus group. You can even go and observe them in action in real life. But the idea is you just get as much information as possible. You need to know your ideal customer better than they know themselves. And you're looking to find out if they think that the problem that you're trying to solve is also a problem. And how much pain do they suffer and will they pay to solve it? And if so, how much will they pay? And if they could solve it, how would they solve it? And do they want an app or a website? And some of these are just some really important questions. The next part is finding out if the problem helps solve your own problems or that of your company, if you're working within one. Does it save your time? Does it enable you to do something that you couldn't do before? And does it transform your business model? Are you more productive because of it? Does it enable you to get more sales? And how valuable is this to you? And thirdly, competitors don't be too disheartened if you see they already exist because it just proves that your idea is a problem worth solving. But you also need to think about who they are and how they tackle the problems you're trying to solve, and they'll have been through the same journey as you. Some of your competitors may only solve a part of the problem you're trying to solve, or they're in a different industry. But it's all invaluable to model your business on their approach. This will enable you to take some shortcuts and improve on their failings, and it's not always the best to be the first mover. Ideas are cheap, execution is everything. With all this information, you can form the problem statement, the persona of your customer and evidence prove that your solution is viable - commercially ideally.

GEORGINA [00:08:49] OK, amazing. So I want to get out there and talk to potential customers and get their thoughts. I want to understand the problem, understand if it's solving a problem for me and my business and also understand my competitors. So understand what they're doing well, but also perhaps where they're making mistakes or missing opportunities, so that I can capitalise on those. Okay, so what should I be seeing at this stage of the process to give me an idea as to whether what I've come up with something that could be a challenge to competitors?

CHRIS [00:09:26] That's another good question, Georgina and for me, if I can identify that it solves a problem that I already face. And then when you speak to others and they confirm passionately that that problem really irritates them, too, I think that's a really good indicator that it's a problem worth solving. People buy with emotion. So look for those emotional responses when you talk to them. If their voice is monotone or they seem unenthused, then they're probably not going to buy your product either, regardless of what's coming out of their mouth. Simon Sinek's ‘Start with Why?’ is a book that will help you understand this emotive side to business. His famous quote, People don't buy what you do, they buy why you do it. And that demonstrates that purchase intent comes from emotion.

GEORGINA [00:10:13] So I'm wanting to find a problem that is a problem for other people, not just for me and a problem that my customers are passionate about when I speak to them. So in terms of developing my idea, how would I go about creating a prototype?

CHRIS [00:10:32] So what you'll notice throughout this episode is that we're trying to prove our assumptions for our idea. This stage gives us another opportunity to find out if what we're doing is worth it. But to do so, we need to test different prototypes of the app to establish how the app should look and feel, but also whether it's still worth developing. And as simple as it may sound, drawing diagrams of how your app will look on a piece of paper is a great first step. Or you can make them on a computer using a tool called Balsamiq. Now these diagrams are called wire frames and essentially, they're just very basic black and white outline drawings of what the App screen will look like. Then you can ask your ideal customer what they think of the idea after they seen these wire frames, then improve the designs with this feedback. You can also turn it into more detailed interactive prototypes using PowerPoint. Now, this even surprised me when I first saw a PowerPoint prototype. Basically, you could create clickable links on PowerPoint where your buttons can jump to another PowerPoint slide imitating what it could feel like using your app. But if you want to take it a step further, there are tools such as Figma and Marvel, which are great for creating very detailed prototypes. Now, you may struggle with some of the graphical elements, but you can hire a graphic designer on the likes of website to help you with some of this, and once you've done this, go back out to your customers and get further feedback on your prototypes. This information is worth its weight in gold. Be careful with asking advice from your friends and family, because no one likes to give you the cold, hard truth that your idea sucks. Strangers are definitely more vocal of their opinions. Now, if you can get these prototypes as close as you can to the final version of your app, then you'll be finding out exactly what your customers really think of it.

GEORGINA [00:12:31] Got it. Okay, so be wary of asking friends and family. Make sure you're speaking to your customers, and also who'd have thought that to create a prototype for an app, I could use PowerPoint. I'm wondering what the advantages of creating a prototype in PowerPoint over getting a designer to knock something up, like a wireframe?

CHRIS [00:12:54] So people have really poor imaginations and they can't really tell you if they would use something or not, let alone buy it. A prototype closes that gap between a black and white drawing and something that closely resembles a real looking App, especially if they could click and interact with it.

GEORGINA [00:13:12] So what would you say once I've got the prototype, whether it's PowerPoint, clickable, interactive or wireframe, what would you say is the best method for then getting that in front of my potential customers and gathering that feedback that's so important to help me make decisions about the next step?

CHRIS [00:13:31] The way I would do it is identify where they would hang out on social media and then post a message, being honest, about how you've had this problem that you've been trying to solve and you're really looking for help from people in this group. Is it possible that you can have five minutes of their time to talk about it? It's amazing how receptive people are when you're honest and open, but people also have a tendency to ignore group messages. So direct messaging and phone calls are far more powerful if you can bump into them in person at conferences or networking events even better.

GEORGINA [00:14:05] Are there any other ways of validating my idea?

CHRIS [00:14:09] Yeah. So another way of validating your idea is to create a Web page, marketing your app idea and how you're going to solve it. You can use a drag and drop website builder to do this. Something like ConvertKit is a great option. And one of the most important elements is to add a checkout page to see how many users actually go ahead and try to pay for it. What I mean by pay for it is literally enter their credit card details. Now, you don't actually take payment from the user. You just redirect them to a coming soon page and you'll email them when it's ready. But this is a strong indicator that you have a great idea. Once you created the Web page, you need to get users to come to your website. So, what you could do is create paid ads on Google or on social media targeting your ideal customer. Or you can manually advertise a Web page on Facebook groups or LinkedIn groups where your target customer hangs out. You can use this approach to figure out how your app should look, features it should have and even different pricing brackets just by creating different versions of your Web page and seeing which is more popular.

GEORGINA [00:15:14] Okay, that's great. So creating a Web page or even different versions of Web pages and targeting my ideal customer to understand how they interact with that and whether they're willing to put money towards this app. There's quite a lot that I can be doing at this stage to check whether my idea is any good, to check whether I have customers that are willing to pay for the app, to check whether I'm solving a problem. How long should someone stay in this part of the process, like, how do you know when you've gathered enough information to then move forward?

CHRIS [00:15:50] So this iterative loop of prototyping should continue on an ongoing cycle. With each bit of information you gather from the previous prototype, you should learn, hypothesize, modify your prototypes and then retest them. Now, there's no hard and fast rule to how long they should take and how long you should do it. But the consensus is the more you do in this stage, the more money you will save throughout the App development process, developers making changes at a later stage can be quite costly, not validating your solving a problem that people will pay for is an even bigger, costly problem.

GEORGINA [00:16:28] You may be have touched on this because you're talking about, you know, having to make changes later in the process and that being really expensive. But is there anything else like what can often go wrong with this prototype stage?

CHRIS [00:16:40] So we talk about these iterative feedback loops, but people can get into internal feedback loops forever trying to improve the idea and never releasing the app. A good way around. This is to set deadlines. Now, another common pitfall is that if you gather feedback from customers, but not your ideal customers, then this leads to false positives or false negatives where your user is affirming something to be true or false, but it doesn't help you on your journey and actually can lead you astray.

GEORGINA [00:17:10] That's also really important. I want to make sure that I'm gathering feedback from my ideal customer and not another audience, because otherwise I could be gathering information that's going to lead me off down the wrong path. Thanks, this whole thing has been really useful. So many insights. Thank you, Chris.

CHRIS [00:17:32] Thanks, Georgina, and thank you for listening. And if you'd like a cheat sheet for this episode, please go to And in the next episode we'll be talking about defining and designing your minimum viable product.

TEASER [00:17:53] And so by the time August came around for Brighton Hove Albion we had something which looks like a good minimum viable product. Brighton Hove Albion got permission from the club to actually sort of go wider than the initial test group and so in 2013 we launched a minimum viable product and went out to every fan within the stadium and Brighton Hove Albion.

CHRIS [00:18:14] This has been a fresh air production for the University of Sussex.