If you’ve ever been scrolling through Instagram, downloading a workout or manically swiping right on Tinder (hey, we’ve all been there) and stopped to wander how these apps actually came to exist then read on.

This post will explain the ins, the outs and the methods used in mobile app development. We could spew out some complicated tech jargon to make us sound intelligent but luckily, we’re not like that. The point of this blog is to emphasize that anyone really can create a winning app – all you need is imagination, dedication and a couple of app developers to help you on your way.

Every app development company will vary in their services offered, but they will all follow roughly the same formula when it comes to developing the product. This blog will explain our processes, how we work with our clients and the methods we use to turn a single idea into an app so addictive it gives people thumb cramp.

How We Work

We use the Waterfall Model in all our projects – which sounds a lot more glam than it really is. Essentially, this allows our clients to stay involved, as we are regularly providing them with a set of deliverables. They can keep up to date with the progress of their project and make sure that we are working to their standard, timeline and specifications.

Where Do We Even Begin?

So many people have an idea for a great app, yet are never given an outlet to produce it. They aren’t confident in their idea, don’t understand tech talk or, in many cases, simply have no idea where to begin.

In our initial kick-off meeting we attempt to extract these great ideas (don’t worry – this doesn’t involve surgery). We want to get the ball rolling, the creative juices flowing and the ideas bouncing back and forth. We’re aware this sounds very hap-hazard and hipster, but trust us, it works. We even provide sweets just in case we’re not quite buzzing enough on tech talk.

When we have settled on something more concrete, our Project Manager will begin structuring the project, making sure the app is both feasible and possible. A first app should be the minimum viable product or MVP (we will write more on this in a future post), so the PM’s job at this stage is to stop the client getting too carried away adding more and more features. We’ve seen the ‘kid in the ice cream shop’ scenario happen too many times, and trust us, it never ends well. The temptation to add something else is always there, so we need to make sure that what we develop really is the MVP, something which can be expanded on once we have some real user feedback.

From here, the PM will put together the functional spec. This contains a full list of the app’s features. It needs to be thoroughly examined by both client and developers, to make sure the requirements and timeline match up.

Design

Once the functional spec has been signed off on both sides, we’re ready to start creating the product. Our two Lead Designers, Elliott and Cris, are creative and passionate – skills which more than make up for their average to poor levels of office banter.

The design is done in two parts. We begin with the UX (user experience), which is the most logical representation of the functional spec. Don’t panic, this will not look like the real thing. Or, if it does, we can only apologise. Full UX design with a list of the functionalities is for the Developers mainly – they’re an extremely intelligent bunch and see things in a different way to the Average Joe. We will deliver the UX design in a user-friendly format to the client. Once that has been signed off we can get cracking with the next phase of design.

UI (user interface) design is where the fun really starts. This is where all the client’s branding, artistic and colour scheme dreams come true (there is no judgement here for dreaming of colour schemes). We want to achieve the right look and feel of the product, so our Designers work closely with the client to make sure it looks as close to how they envisioned as possible. Now and again the client pops in to see us, which we like to think is because we are great people to be around, but it’s just because we have really nice coffee.

Once the UI design is delivered and signed off, there are high fives all round and we might even make the Designers a cup of tea. After that: development begins (cue dramatic music).

Implementation & Verification

It is a common misconception that testing is done at the end of the project, however we’re firm believers that we should identify and fix unexpected results at each stage of a project, rather than allowing problems to escalate – resulting in nervous breakdowns all round.

The development and testing phase of the project is where everything starts to get a bit techie and, depending on the size of your app, this can take anything from 4 days to 1 year.

The first step in the development process is for our Front End Developers to translate the visual design laid out by our designers into a clickable prototype. A clickable prototype does what it says on the tin, you can move between screens and experiment with transitions – however none of the functionality has yet been applied.

Following this we work to implement some of the more basic API endpoints such as registration and profile creation before releasing an alpha build to the client. An alpha build will still be very “raw” but will have passed stringent QA acceptance criteria.

Only when the app passes our QA team’s extremely high standards and the core functionality is in a usable state will we release the first build we consider a “beta”. The beta stage is the first chance to start testing the full flow of a mobile application, from registration through to completing all user journeys. Stress testing continuously to mimic real world usage; at this stage we will be looking for bugs, unexpected behaviour and crashes.

There is usually a large amount of work to do between the first beta build and an app that is fit for the app store, often an app will go through multiple beta releases that progressively get closer to your launch specification. Only once all the bugs have been ironed out will the build be considered “launch ready”.

Maintenance

Just because the app has launched doesn’t mean the work is done. If the client signs a maintenance package with us, our PM will develop a plan with weekly sprints to develop and support all features of the product. If something goes wrong, we are onto it. From here, the client can start collecting some analytics and stats, helping them to plan for the second version of their product.

Version 2

They say you only start really learning to drive once you’ve passed your driving test and the same could be said for apps. Once we get some real user feedback we can work out what we can do to make it better, and that is when we start work on version 2. This also is the time for the client to start adding in some new features, think about monetizing their app if they haven’t already, and gain some insights into how users have been responding so far.

We hope this post has encouraged you and made you realise that mobile app development isn’t quite as complicated as it may first appear. Please get in touch if you want to know a bit more about the services we offer, or just fancy a chat about how your day is going.