You’ve had that lightbulb moment, a great idea for an app you want to make, but you’re not sure how to make it happen.
You’re not the only one. The truth is there are a lot of people out there who have had ideas around creating their own apps. The real difficulty is getting it made which is why we’ve produced this 12 step list that you will need to follow to make that dream app a reality.
Step 1: Define the problem your app will solve
Step 2: List the ways in which your app solves the problem
Step 3: Create a user flow for your app
Step 4: Sketch The Design And How It Works
Step 6: Defining a scope for the build
Step 7: Define how much you want to spend on the build
Step 8: Managing the app build
Step 10: It’s time for Beta Testing
Step 12: Get ready for the next launch
Whether you’re building an Android app or an IOS app the first step in the process is always the same:
Being clear about the problem that your app solves and why people should use it.
To do that start listing all the problems you hope your app will solve – don’t worry about how many you come up with, you can filter these down at a later stage.
The below is a rough example of the thought process around it and how to structure it:
We need an app for our stakeholder meetings.
Problems our App needs to solve:
It’s as simple as that. Just outlining your idea and then bullet-pointing the key problems that creating your app will solve.
Before we can start with developing and designing your app we need to make sure that it will work and there’s an audience for it. To do we have to figure out how your app idea will solve a problem and what its core purpose is.
The process for that is;
So following on from the earlier example you’ll add something like the below to the bullet point list of the problems:
How our app will solve the problem:
This next step in creating an app is really important as you need to think about how your user will interact with the app.
You can see that in the step above we have already started to think about it – just expand on this and let your ideas and questions flow.
Here is how we would roughly approach the process.
The most important part that isn’t mentioned above is having someone moderate the room. Both having an external moderator (like us) and using the fun games help prevent the room from being hijacked by those who have the loudest voice.
The above process is known as a Design Sprint and was created by Google Ventures to come up with innovative products in its businesses. It has since been adopted by organisations of all types because it is highly effective and very time efficient.
The next step in the process of making an app is to sketch it and visualise it for the first time. This step gives you and your stakeholders the opportunity to show what they have in mind and how the app could look.
To do that we give each of the people in the room a giant A3 sized phone cut-out with a set of coloured pens. They have previously listed what the app is going to do and have voted on the key functions. Now they have to draw their interpretation of how this will actually look on the screen.
It does not matter if they cannot draw – it’s not an art competition. We want to know how they see it in their own minds. You will be surprised at differently people visually interpret the concepts they have all agreed on verbally.
Trying to draw something is a great way to spot things you had not thought about or refining ideas. When everybody in the room shows and tells their app design this is when you start to see a collective vision of what your app should look like.
If you go through the process described above with Page Lizard it will be run by one of our mobile app UX designers. They will have kept their professional opinions to themselves – but they will have gathered great insight into what you want and taken on board all the great or crazy ideas you came up with.
Testing the app design on real people is one of the key steps in creating an app. You’ll need to make changes as you go – this will also help you avoid one of the biggest problems of any product innovation: bad UX design.
To do this we use a design programme called Invision and you can load it on a phone or tablet so that it looks like the real thing. We’d then grab our friends, family, employees or, best of all, potential users and get their feedback. You can also use it to run focus groups and monitor how users react.
At this stage, all you have invested in is a series of designs for each screen. It’s really quick and easy for the designer to modify these. It can even be done between app testing sessions so you can test the new design versus the original app design.
You now have a prototype of your app that’s tested on real people and you are ready to proceed to the next step of creating an app.
The purpose of the scope is to find out how much it will cost to build the app and how long it would take. Sharing a working prototype and asking for a quote to build it is unambiguous. You’ll get exactly what you’ve asked for plus maybe a few things you didn’t think about.
That versus sending a list of ideas where they can misinterpret them is much better.
That doesn’t mean there aren’t any pitfalls. Two key things to look out for are:
A well-defined scope for the build solves a lot of these problems. It defines exactly what you’re looking for and every feature that you want in it.
You’ve now got a clearly defined product and you’re at the stage where you need to be clear on how much you’re willing to spend. The answer to ‘what does an app cost to build’ depends largely on who you are talking to.
Here you have several options of how you want to build your app – see our blog about the options Building an app DIY or outsource . You can commission a developer to build it for you from scratch or you can use a platform solution which uses modules which saves you time and money.
If you use a platform solution and brand a generic app in return for a monthly licence fee, the advantages are that the costs will be much less, potentially a quarter of those of a developer with the added bonus of permanent updates (if you are looking out for the right platform).
However, if you commission a developer the cost will depend on the requirements. So, for example, let’s say they come back with estimates that are in the ballpark of 800 hours at a cost of £130 an hour – so you’ll need a budget of £104,000.
Even if £104,000 matches your planned total spend, you don’t want to have all of it on one final perfect product. Instead, figure out what will be acceptable and build off of it. Otherwise, it’s like taking all your money and putting it on red.
A savvy app builder will at this stage work out what is their Minimal Viable Product (MVP) for launch. An MVP Product is essentially the most basic version of your product that is good enough to launch. This allows you to get feedback on its performance and dedicate your budget towards what the users really want.
Some key questions to ask when deciding on an MVP
Once you’ve settled on your MVP you can properly phase your budget. For launch, we will have an initial spend of £65,000 for 500 hours and we will keep 300 hours back to build upon it once we’ve got more insight. Or you use a platform solution (as mentioned above) and you’re looking to spend potentially a quarter of the fee a developer would charge.
You need to decide who is managing the build. You – as the app owner – need to assign somebody. Here you have three commercial options available to you for building an app:
Anyway, whoever is developing your app, you should have a call with them on a weekly basis to learn how each phase of the sprint is going, any problems arising and to answer any questions they have for you. It may only be 15 minutes, but it gives both sides the chance to ask questions that might otherwise get papered-over with assumptions. Everyone knows that development projects over-run and scheduled calls like this are the best way to minimise overrun and make small decisions on the go.
It helps the development company to have an app owner who has the authority to make decisions and chase up third party suppliers. It also helps you to build a rapport with the app developers.
Above all, by being involved you will get a good sense if you chose the right company for you.
Within a few weeks, the app development company will have turned your prototype design into a real working app. It should be still unfinished when you get to see it the first time and will be for internal testing only.
This is where you test different features of the app, report things that are broken or slow loading, and give the developers the feedback they need. Testing and bug-fixing is a difficult process for both sides and there are a few key questions you need to answer before you start:
Hopefully, you will have good project managers and QA’s (Quality Assurance Testers) on both sides who are used to the process. To test well, stick with the plan. This is not the time to deviate from the budget and MVP – be calm, cool and diligent and you will get there.
You’ve created your app and put it through your internal testing process. Now it is time to release it to a wider pool of testers – those friends, family and employees – and some trusted end users we spoke about earlier.
We use TestFlight to release iOS apps. The programme is owned and run by Apple so you must have already submitted it for approval before Apple will allow it to be shared via TestFlight. You send your testers and invitation to join by email and, once accepted, they can download the app and use it for real. The app is actually in the Apple store, just not publicly available. You can invite up to 10,000 people to test your app.
Once you have a version which you are happy with it can be turned into the ‘live version’ and released to the public.
For testing Android apps we use Test Fairy. This is not controlled by Google or any of the stores and is a platform that lets users download the app files and install them on their Android device. Once testing is complete you, or the developers will have to submit the app to the Google Play store to enable it to be seen publicly.
It goes without saying but any bugs or negative feedback that you get needs to be addressed.
Now you’ve built an app and it’s been tested and approved comes the hard part. Making sure people are downloading and using it!
There were almost 2.5m apps in the Android store by the end of 2019 and 1.8m in the Apple store. Windows and Amazon stores account for a negligible number of apps and are not a factor unless you need them for a specific reason.
In the early days publishing an app to the stores would guarantee you downloads. Nowadays you might as well assume your app will remain undiscovered, though there are plenty of companies who will offer App Store SEO services and find ways to bump your mobile app up the visibility list.
The promotions our clients specialise in are reaching out to their internal audience. Here are some tips we give those companies:
The biggest mistake people make with apps is thinking that the mobile app development process ends when the app is in the store. Check out the apps you have downloaded already and you’ll see a long history of app updates which include fixes, performance improvements, changes, and new features.
An app will have a total life of about three years before you need to chuck it in the bin and invent it again. In that time you will re-release it at least six times.
Apps are still a relatively young technology and are still in the rapid evolution phase. They are built on platforms – iOS and Android – which are fighting to deliver the best smartphone technology in a hot and massively lucrative market. They are constantly releasing new versions of their operating systems which means app developers are constantly fighting to keep up.
This is why Page Lizard offers all app builds on a SAAS (software as a service) model. The client does not own the software that runs the app – they ‘lease’ it if you wish – and we keep the software up-to-date with all the iOS and Android platform changes in exchange for a monthly support and maintenance contract.
The last thing you want as an app ‘owner’ is to actually own your app code unless you have the development team who can keep it up-to-date 365 days a year.
We also work with clients on an active development plan to coincide with the six-monthly re-releases. Why not combine the next release with a staged release of the next function? Your users like it when the app is constantly improving, you can boast about new features, you can use the occasion to remind them why it exists. An active programme creates a virtuous circle of improve, learn and improve.
Get in touch with us.
Join the Reptile Community
January 20, 2023
Discover how citizen developers are changing the game for businesses
March 31, 2023