App Developer Studio

Published 15 March 2022

10 steps to start to build an app

The 10 steps involved in getting an app built, from gathering requirements to prototyping to development to testing and successfully submitting the app to the app stores.

Don't worry. We've got this.

So, you know very little about apps or technology? You just have a great idea. We are here to guide you through the process to bring it to reality. You probably have a lot of questions running through your mind... "How do I protect my idea?", "How much is it going to cost?" "How will it make money?"

You might have already spoken to some other developers or even unsuccessfully started with one of them - almost half of our clients come to us to "rescue" their current projects. We want to build long-term relationships with successful apps and clients. Therefore it is in our interests to make sure we help you achieve your app's full potential.

So here are our 10 Steps to get your app built:

  1. Let us know what it must do. We probably get 10 calls a week along the lines of "how much does an app cost?". Come on, that's like asking "how much does a car cost?"! For us to be able to provide an estimate, we need to know a bit more about what the app must do in your own words. This helps to bring it to life for us so we can understand the probable requirements based on our long experience. It helps to start with “User Stories” which is writing, in plain English, what the different users of the app will be able to do in it. Don’t worry about how this is technically delivered. That’s our job. You can start by completing our short questionnaire that asks all the important questions we need the answers to. 
  2. Protecting your idea - Are you uncomfortable sharing your idea with us? Don't worry, we are not offended. It's understandable. We're happy to sign a Non-Disclosure Agreement (NDA). You can download, sign and email ours and we'll countersign and return. Or we can sign your NDA if you have one.
  3. Let's talk - Once we have a good understanding of your requirements (this might take a bit of to and fro via email), ideally we would meet or speak to you to finalise any questions that are easier to discuss. Our clients find these sessions very useful because we can offer advice in terms of the Minimum Viable Proposition (MVP), monetisation models and potential platforms we might be able to use to save time and cost. Our clients are often surprised with our recommendations on these calls, for example, “why does this need to be an app and not a website or a bot?” or “Apple will not approve an app like that unless we change X, Y and Z”.
  4. Proposal - Once we are clear on the requirements, we will work on a detailed proposal with our development and design teams. This will provide information on the deliverables, technology stack, cost by task, timeframes and payment schedule.
  5. Payment - Our normal payment schedule is a 40% deposit followed by 20% payments when we hit certain development milestones that are agreed upfront.
  6. Prototyping - For large projects, we (nearly) always start with a prototype in Figma showing all the main screens and User Interface/ Navigation elements. It is better to start with a laser focus on the user experience before it gets lost in the tech. Besides giving you something to show potential investors or stakeholders before the app is launched, it also confirms all the technical deliverables because there is nowhere to hide. Every key screen, button and function is shown so we know what must be built. We typically start with a brainstorming/kick-off workshop with our design team, a whiteboard and lots of great coffee! 
  7. Development - Each project is different, but we utilise Agile Project Management methodology with weekly or fortnightly Sprints with clear deliverables. Every client and project is allocated a single point of contact, a Scrum Master based in South Africa who is always available to answer any question you have and provide regular project updates through weekly client calls/ demos. We typically manage our team through Slack, our project management on Jira and the code base via GitHub.
  8. Testing - We take testing very seriously. Not only to ensure you and your customers have a flawless user experience but also because our project costs (and your frustration) can rise very quickly without proper version control and bug list management. Fortunately we build high quality code and using tools like FlutterFlow and Firebase really help with this.
  9. Marketing, Store Listing - During the project we will normally discuss with our clients their marketing requirements. At a very minimum we need to work together to prepare and optimise the app's listing on the app stores to ensure maximum exposure from launch.
  10. App Submission to Store - The most common reason apps are delayed is that they are not built to Apple and Google's requirements and so get rejected by them. In addition to designing stable, beautiful apps we fast-track this process by normally submitting a beta version to the stores well before the launch deadline. This helps us to pre-empt any rejection issues for the final app. Apple in particular are very rigorous in their app approval process.



Laptop showing the work we do
Office
Work With Us

Have a project? Let’s Work Together!

We design, develop and help you to launch apps, websites and bots.

StarStar

Questions we get asked

Frequently Asked Questions

What's the first step to building an app?

Tell us what the app needs to do, in your own words — starting with 'user stories' that describe, in plain English, what different users of the app will be able to do. Don't worry about how this gets delivered technically; that's our job. You can start by completing our short questionnaire, which asks all the important questions we need answered.

Can I protect my idea before I share it with a developer?

Yes. If you're not comfortable sharing your idea with us, that's understandable and we're not offended. We're happy to sign a Non-Disclosure Agreement — download, sign and email ours and we'll countersign and return it, or we can sign yours if you have one.

What happens once you understand my requirements?

Once we have a good understanding of your requirements, we'll ideally meet or speak to finalise any questions that are easier to discuss — covering the Minimum Viable Proposition, monetisation models, and potential platforms that could save time and cost. From there we put together a detailed proposal covering deliverables, technology stack, cost by task, timeframes and payment schedule.

What's the payment schedule?

Our normal payment schedule is a 40% deposit followed by 20% payments when we hit certain development milestones that are agreed upfront.

Do you build a prototype before development starts?

For large projects, we nearly always start with a prototype in Figma showing all the main screens and User Interface/Navigation elements, so the user experience is right before it gets lost in the tech. It gives you something to show potential investors or stakeholders before the app is launched, and it confirms every technical deliverable because every key screen, button and function is shown upfront.

How is development itself managed?

We utilise Agile Project Management methodology with weekly or fortnightly Sprints and clear deliverables. Every client and project is allocated a single point of contact — a Scrum Master based in South Africa — who is always available to answer questions and provide regular project updates through weekly client calls and demos. We manage our team through Slack, our project management on Jira, and the code base via GitHub.

How do you make sure the app gets approved by the app stores?

We take testing very seriously throughout development, since poor version control and bug list management can make project costs (and frustration) rise quickly. During the project we also discuss marketing requirements and work together to prepare and optimise the app's store listing. The most common reason apps are delayed is that they aren't built to Apple and Google's requirements and get rejected, so we normally submit a beta version to the stores well before the launch deadline to pre-empt any rejection issues.