View all newsletters
Receive our newsletter - data, insights and analysis delivered to you
  1. Technology
  2. Software
January 5, 2016updated 31 Aug 2016 12:17pm

How to build an app: 5 mobile development masterstrokes

C-level Briefing: Paul Swaddle, CEO of Pocket App and star of the Apprentice final, explains the tricks behind developing a great app.

By Alexander Sword

How much does it cost to build an app? Exactly as much as a car.

This is the answer that Paul Swaddle, CEO of Pocket App, the UK-based independent app developer, gives whenever he is asked this question.

"The analogy works quite well, because you can get something for under £10,000," says Swaddle, who recently featured in the final of the UK Apprentice as an app expert. "It will do the job, if the job is to get you from A to B in an economic manner and not be a great performer.

"But the vast majority of cars are in the £20,000 to 30,000 bracket, and in that price range you get apps that do something and do it quite well. Clearly you can spend £1 million on a car or an app."

What Swaddle’s argument highlights is that companies often go into building applications either for their customers or their employees with a range of misconceptions of what will be involved.

So how should enterprises approach app-building? Here are some pointers from the Apprentice star.

 

Content from our partners
Unlocking growth through hybrid cloud: 5 key takeaways
How businesses can safeguard themselves on the cyber frontline
How hackers’ tactics are evolving in an increasingly complex landscape

 

1. Solve the money question

The app journey starts with what Swaddle refers to as a discovery call.

"What we try to do quite early on is qualify whether they have any money. Ideas are relatively cheap, so it’s about setting expectations."

Of course, as Swaddle explains, the knowledge of the price of an app is often lacking.

"Some people think it’s going to cost a few hundred quid, and that is clearly not realistic. We go through and help the client decide what the key elements are."

The car analogy comes back into play here:

"Once you start to get into the £20000s and 30000s, most of the bells and whistles come. From there it is the extra stuff. Obviously if your app is Tinder, when you first build it, your back-end needs to work, not be a Ferrari. Later you may need several Ferraris."

 

2. Decide what you need

Part of Pocket App’s job is to help their customers decide what they actually need rather than deliver what they think they need, as Swaddle explains:

"The first phase we refer to as a design workshop: going through the issues, working out what are the problems and what are the solutions. Some clients come with more or less of the solution defined."

"Often it is trying to get people to step back and decide what the problem they are trying to solve is and not what they think is the solution. They come at it saying what they want. We can step back and say, why do you think that is what you want?"

What arises from this stage, before any coding is done, is a basic simulation of the app.

"Typically at the end of that, having worked out what it does and designed what it will look like and the style, we end up with an interactive prototype. This is a visual prototype that can be stored on the device.

"The digital prototype, we find businesses use it for updating the board on how it’s going or for approaching investors for the round of investment you need to get to the next stage. That is relatively cheap and could take anything from five to 15 days of work, whereas the app build might be anything from 20 to 100 days."

 

3. Develop the app

Once the prototype is ready, the building takes place.

"We develop to an agile process: two-week sprints, releasing the product as we go. We find that eliminates some of the errors that can happen when there’s a divergence of what the client has in their mind and what is being delivered, particularly if they’re still thinking about it."

The app soon reaches a level where it is ready to reach users.

"Then we get to a user acceptance testing version, a version of the app that is typically 97 percent done. We might still be waiting for some copy for some sections from the client or there is an API missing, but the vast majority of it works.

"Having done that and refined that in final phases of testing, we get down to a release candidate, or an RC. Then we release to store."

 

4. Choose: third-party or in-house?

A lot of companies have in-house development teams or at least employees with some expertise. Swaddle explains why it is not feasible to have enough development skills on-hand for most enterprises.

"Unless you are a very large company building a lot of apps regularly, you can’t have the skill base in-house to do that work. It’s a bit like saying that you make TV ads, so we should hire a production crew because it might be cheaper if we hired them all directly. But what do you do next week when you don’t need it?

Where Pocket App’s clients do have in-house developers, they typically take on the maintenance and ongoing work rather than the actual development. Swaddle likens hiring an app developer to another less high-tech example.

"You wouldn’t not get in people even for something simple like building the bicycle shed outside the office. You could hire someone with the right skills directly, but would you know whether they’d be any good? Could it go horribly wrong?

"So you get a construction team to do it and if they do a good job you choose them for the next one."

 

5. Choose: style or substance?

Swaddle explains how the special status of the mobile device makes what runs on it all the more crucial.

"This is not just a very small computer; it happens to be that but it is used in a profoundly different way," says Swaddle.

"Mobile is so personal; it is your identity. What does that mean to brands? Getting it really right can be really powerful but getting it a little wrong can be very powerfully bad?"

This means that functionality is actually secondary to the user experience.

"On a mobile device, a normal consumer would rather something that is beautiful and has one or two features that don’t quite work than something that works but is ugly.

"It’s because it’s their space; the apps that you choose to put on your home page is a statement about who you are and what you do and you don’t want stuff that’s not nice."

Building an app badly won’t just stop people using the app; the negative effects could spread to the perception of the brand itself, Swaddle explains:

"People are very intolerant of bad design on a mobile device. If it doesn’t look right then they won’t put up with it, particularly once you get beyond the early adopters.

"If you’re a brand, it can seriously damage your reputation if you get it wrong. However, if you get it right you can reinforce your brand values."

 

Websites in our network
Select and enter your corporate email address Tech Monitor's research, insight and analysis examines the frontiers of digital transformation to help tech leaders navigate the future. Our Changelog newsletter delivers our best work to your inbox every week.
  • CIO
  • CTO
  • CISO
  • CSO
  • CFO
  • CDO
  • CEO
  • Architect Founder
  • MD
  • Director
  • Manager
  • Other
Visit our privacy policy for more information about our services, how New Statesman Media Group may use, process and share your personal data, including information on your rights in respect of your personal data and how you can unsubscribe from future marketing communications. Our services are intended for corporate subscribers and you warrant that the email address submitted is your corporate email address.
THANK YOU