Once you have completed the design stage (which we featured previously here) and you’ve got the full set of user journeys and design prototype, now it’s time to build it!
What do I need to begin development?
The design stage should have provided you with a wireframe, showing all of the app’s screens and how they connect, and visual designs for each of those screens. In our case, we also build an interactive prototype to give a sense of how using the app will feel.
There is one final vital component, which sits right at the crossroads between design and development: a detailed technical specification. This takes the wireframe and annotates in more detail – how it will actually work, as well as how it looks. For example, if one screen is pulling in external data, where is that coming from? Which server is that from?
What happens during the development stage?
Fairly simply: the app is built. In our case, this is done in what are known as development sprints. This is part of the Agile methodology, and breaks development up into periods of around two weeks apiece, each focused on a particular bit of functionality.
At the end of that sprint, a build is released – normally to the client, but certainly internally – for review and testing. A Quality Assurance team checks that the new functionality is working, and that its introduction hasn’t broken anything that was already there.
It’s best to work transparently, so that clients can have full granular visibility on each stage of the process, and know how everything is progressing.
Once all these development sprints are complete – typically, there might be seven of them in a project – you have what is known as a UAT (User Acceptance Testing) version, for the client to test and sign off on.
At that point, it moves to RC (Release Candidate) status, where all necessary refinements are made so it can be pushed out on the app stores, or the client’s website, or whatever release looks like for the particular project. Expect to see a few iterations of this version.
What are the outputs from the development stage?
By the end of development, you’ll – obviously and most importantly – have the developed product itself. But we also give clients the full functional specification, and the full source code for the project.
We firmly believe that it is the client’s project, not our project. Although naturally it’s preferable to keep working together, this enables you to do whatever you want with the app going forward, rather than being locked in to a single developer.
How long does development take?
The full build process, to get to the day-one version of your app, is typically between three and six months long.
Anything more than that, we’d advise breaking it down and doing an early release with some proportion of the full functionality so you can start learning. And it’s worth remembering that, even if this isn’t the case, the day-one app won’t include all of the functionality planned out during design. We capture all ideas during that stage, but as the build is typically limited by timeline and budget, some are held back for future releases.
This is helpful because, once an app is live, there is a lot to be learned from analytics. Perhaps people are using one part of the app more than you expected, and something that was intended as a main feature is largely being ignored.
This kind of discovery can inform your plans as the app develops beyond day one. You might put more resources into the unexpectedly popular feature. It might be worth dropping further development for the underutilised feature – or working to signpost it better within the app. These are considerations for the next stage, support and maintenance.
What should I be considering during the development stage?
Security is important, but exists on a spectrum
We’re often asked how secure an app needs to be. The answer depends on the specifics of your project. There’s no single industry level of app security, so consider: how sensitive is the data involved?
If it’s a recipe app that’s just storing a list of what the user has in their cupboard, it’s probably not a huge concern. But if you’re handling personal data, or it’s an internal app that processes commercially sensitive data, then it needs to be a priority. Even if the data isn’t particularly sensitive – like names and addresses, which can be accessed through other means – be aware of how your customers are likely to view it.
Dynamic functions require a reliable data source
If you want to your app to pull, for example, a list of nearby restaurants that do a particular kind of food, then you need to consider where that will be sourced from, and how you will gain access to it.
Even if it’s internal data, be aware that legacy systems can provide an obstacle. They may not have been designed to handle the number of calls a consumer-based service can make; in older companies, they may even pre-date the web.
In this case, our solution is generally to build a middleware layer, optimised for communication with the app, that sits between client servers and the app itself. This will pull the data on a regular basis and then make it available to users in the app, without requiring an overhaul of legacy systems.
Understand the difference between the first and final releases
Iteration is a big part of the process. So don’t expect every version you see to be fully functional. It’s better to see those early versions rather than wait until the end, because it enables you to influence development while it’s in progress.
Part of the Agile methodology is that, if your priorities change – which they likely will – during the length of project, you can swap out functionality on a modular basis, as long it’s switching like for like in terms of complexity.
