A Complete Guide to Outsourcing Your App Development

So you want to create an app. Are you non-technical or don’t have experience managing a software project? Read this guide.

Creating an app is difficult: So many moving parts and so much foresight needed. Every decision has long-term implications to your app.

Non-technical people usually struggle with making good technical decisions. So, many people have found success by outsourcing their software app development to an experienced agency or freelancer. But outsourcing is either the solution to your non-technical gap or the start of your many problems to come.

Contents

Introduction to Outsourcing

So what can a non-technical person do? You can learn the key concepts of software development and quickly become familiar with these areas. This guide provides comprehensive coverage of software development areas that you should consider to be more successful. If any of these areas are important to you, dig deeper, and do your research (or ask MSE for help).

Part A: Ideation

You have an app idea. Great!

Now, put this idea down in writing so that you can effectively communicate what you want to your outsource developer.

Articulate Your Concept

💡Articulate your concept clearly, but succinctly in a document format (e.g., MS Word). At minimum, write down one sentence, a “requirement,” for each app feature you want. Here are requirement examples based on Amazon’s shopping app:

The user shall browse the products in the store as a ‘guest’ without logging in.
The user shall add products to their shopping cart.
The user must login with their email and password to checkout the items on their cart.
The user shall register an account with their email and password.
The user must accept the End User License Agreement (EULA) before completing user registration.
The user must review their shopping cart during checkout.
The user must enter their credit card information during checkout.
The user must enter their shipping information during checkout.
The user shall receive an email confirmation upon successful payment at checkout.
The user shall receive an email notification when their order has shipped.

Here, one sentence requirements is the minimum. You should go further and describe the problems that you are trying to solve with an app and be clear about what success looks like. A more structured way of doing this is by creating a Lean Canvas or Value Proposition Canvas.

The goal is to stop your outsource developer guessing and making assumptions about what you want. Guessing/assumptions always lead to “padded” estimates. If your developer has experience in this space or type of app, they should be helping you refine your requirements and guiding you by asking all the right questions during the discovery phase of the project.

Visualize Your App

Your requirements are in good shape. How else can you convey your app idea?

Humans are visual. If you know exactly what the app should look like and if you have design skills, a wireframe design of your app is a great way to bring a visual element to your concept. It helps a developer understand the words behind your requirements.

Any time you put in the effort to bring clarity, you are reducing uncertainty, which always means reducing development costs. If you don’t have wireframes, you should ask your outsource developer to produce them. The goal is to ensure that both parties are on the same page.

💡We recommend creating wireframe designs for every screen before writing a single line of code. You can use any tool for this (including pencil and paper), but we recommend App Composer or Figma so that you have high-quality wireframes for the developer.

Identify Target Devices

How are your users are using your app? More specifically, are your users going to be using Windows, Apple, or Google computing devices?

For the app to support different devices, the developer must use different development tools and coding languages. The Windows, Apple, and Google operating systems on these mobile devices are not compatible with each other.

A mistake here is asking for a “native” app, meaning an app written specifically for one device type only. The issue is that a native iOS (Apple) app will not work on an Android (Google) device and so the developer will have to develop the app a second time for native Android. Obviously, this doubles your development costs.

Are native apps necessary? Hint: 90% of apps don’t need to be native as the requirements and usage are not complex enough to benefit from the performance gains of a native app. If you hear languages like Swift or Kotlin, these are coding languages for native apps.

💡To keep the development costs low, we recommend a hybrid app. The developer codes a hybrid app once, but uses the same code for the app on multiple devices. Languages like Angular, Ionic, React, or Flutter are coding languages for hybrid apps. With a hybrid app, users still get the benefits of finding the app from the app store, installing the app, launching with a shortcut, etc., but without the higher cost of developing multiple times.

A web app is actually a website with “responsive” design, meaning that it displays properly on all screen sizes. Because it is a website, it needs an internet connection to work, accessible by entering the URL in a web browser, and is not installable or launchable with a shortcut. However, a Progressive Web Applications (PWA) allows the user to “install” the app on the device so that it is accessible via a shortcut.

💡We recommend discussing with your outsource developer about which devices you want to support (see list below) and whether you want (vs need) your app to be native, hybrid, or a web app.

Mobile: Apple iOS
Mobile: Android
Mobile: Web
Desktop: Web
Desktop: MacOS
Desktop: Windows

Other devices to support may include:

Watch: Apple WatchOS
Desktop: Linux

The ultimate goal of identifying your target devices is to confirm whether you are spending the right amount (i.e., not for more than what you need).

Confirm Required Technologies

Now that you have documented the desired features of your app, it’s time to consider how to deliver these features using mobile app technologies. The ability to deliver these features depends on built-in operating system features or third-party tools/services, which come with on-going costs (e.g., annual license or monthly subscription fees).

The following are examples of dependencies that may apply to your app:

Identity Management: This is the most basic form of app security. It’s for user registration, login/logout, account management, and private information (e.g., payment information, shopping cart, order history, etc.).
Agree to Terms: For obtaining the user’s acceptance of the terms & conditions of using the app.
On-Boarding: For providing users with a tutorial about the app during their first use. This is typically explains what users can do with the app or how to use certain features of the app.
Static Pages: Static pages on your app are like a photograph. It’s content never changes because the data is permanent (or hard-coded) into the page. Changes to static pages will require re-development (i.e., code changes). Examples are Hours of Operations, Contact Us, About Us, FAQ, and Help pages.
Dynamic Pages: Dynamic page contents change based on the user’s activity or fetching data from an external system. Examples of this are items in your shopping cart, order history, credit card information, current weather temperature, current stock price, etc. Essentially, any data that you want displayed in your app that the developer cannot code right now.
App Navigation: How do you want users to navigate throughout your app? The choices are typically top toolbar menu, side menu, or bottom toolbar.
Orientation: What is the desired orientation of the device when using your app? The choices are either portrait or landscape.
Screen Sizes: What screen sizes (i.e., resolution) do you want your app to support? Identifying the sizes early ensures that the developer is testing the app pages with every screen resolution.
Push Notifications: For the user to receive an alert on the device (e.g., you have a new friend request) while the user does not have your app opened. This is great for sending information to the user when they are unexpecting this information (i.e., they are not checking your app for updates).
In-App Notifications: For the user to receive an alert in the app itself while the user is using the app (e.g., you have 5 unread emails, you have 3 new friend requests, an item in your shopping cart is on sale). There will be an indicator or counter within the app (called a badge) to bring attention to these notifications.
Email Notifications: For the user to receive a communication via email. In addition to push and in-app notification, you may also want to send an email to the user with all the same information.
In-App Messaging: For users to message or chat other users of the app. Both Facebook and LinkedIn provide in-app messaging so that you can contact another user directly without leaving the app.
Map: For displaying map information or using map functionality like directions, reviews, hours of operation, etc.
Location Services: For the app to know a user’s location. Location-dependent features (e.g., current weather) uses location services to present the data based on the user’s current location.
Biometric: For the app to use the biometric capabilities (e.g., Touch ID, Face ID) of the mobile device. For example, you may want to use Biometric to speed up the login process or to confirm an order during the checkout process.
Camera: For capturing a photo or a video using the camera of the mobile device.
Multimedia: For the app to display or play multimedia content such as photo, video, animation, or sound.
Graphs/Charts: For the app to provide data visually.
Data Collection: For collecting data from users via forms and data fields (e.g., first name, last name, address, gender, social posts, comments, likes, etc.).
Data Sourcing: For connecting to other systems to fetch data needed by your app (e.g., get current local temperature).
Data Transfer: For connecting to other systems to send data from your app (e.g., post to Facebook).
Data Storage: For storing data generated or needed by your app. Choices are an embedded database inside the app for smaller datasets; or a remote computer server (e.g., AWS) with a relational or NoSQL database for larger, structured datasets.
Data Encryption: For encrypting the data managed by your app. This can include encrypting the data in the database (i.e., encryption at rest) or encrypting the data when transmitting to another system (i.e., encryption in transit). For example, all banking applications will encrypt your data that it collects (encryption at rest) and also ensure that you are communicating with the bank on a secured connection (encryption in transit or HTTPS).
Offline Mode: For giving the app abilities to operate without an internet connection. For example, you can download movies on Netflix to watch later on an airplane without internet connection.
In-App Purchase: For providing users to buy products or services directly from within your app using Apple’s or Android’s built-in payment wallet feature. This is a convenience feature that eliminates the user’s need to enter credit card information to make a purchase.
Subscriptions: For providing users with the ability sign-up for subscriptions from within the app. Recurring in-app purchases (e.g., monthly Disney+ subscriptions) is seamless because the operating system (e.g., Apple App Store) handles the recurring payments.
Payment Processing: Accepting credit card payments from within the app by integrating into services such as Stripe, Square, or PayPal.
Analytics: For tracking user activity including user navigation, page clicks, geolocation, errors, etc. Analytis data is useful for improving the app or improving user engagement.
Instrumentation: For tracking errors and general metrics about the app. This is helpful for diagnosing problems and fixing the app.
Monitoring: Tools like CloudWatch for providing you with real-time alerts. This can detect problems with your app such as a server degradation, network outage, or storage issues.
Accessibility: For providing disabled users with alternative/improved tools for using your app.
Languages: For supporting multiple language translations based on the user’s chosen language.
Files: For receiving or attaching files in the app. For example, users accessing their photos for attaching to a Facebook post.
Performance: Ensuring the app and its dependent technologies can scale and handle the expected number of concurrent users during peak times.
Advertising: For monetizing your app via inline ads. Many free apps and games use inline ads for incremental revenue generation.

Provisioning all of these features/services for your app are time-consuming. MSE bundled these into Acceleration Blocks, which we use to accelerate our app development projects.

Check Regulatory Requirements

Apps collecting data have additional requirements for data privacy and data protection. Laws exist at the state, federal, and also continental level for governing certain kinds of data and its intended use.

The following are data regulations that may apply to your app:

HIPAA: If your app handles patient data, you are responsible for HIPAA compliance to protect the privacy and security of the user’s health information. Let your developer know about HIPAA compliance so that Protected Health Information (PHI) has encryption and authorized access protection.
PCI: If your app is handling credit card transactions, you are responsible for PCI DSS compliance to ensure the security of credit card transactions. Let you developer know about PCI compliance so that payment card information has the necessary encryption and protection.
GDPR: If your app is handling data of users from the European Union (EU), you are responsible for GDPR compliance for handling data of your users, including the ability for users to remove their data from your app.
CCPA: If residents of California are using your app, CCPA compliance applies. This law gives California residents better control over personal information collected by businesses.
Biometric: If your app uses biometric features of the device, you are responsible BIPA compliance to obtain the consent of the individual before collecting the user’s biometric information.
Encryption Export Compliance: If your app encrypts data and your app is available outside the USA, you are responsible for Encryption Export Compliance.

Part B: Legal

Now that you have the concept and vision captured, let’s go find a developer? No, stop! You’re not ready yet.

First, consider protecting yourself and your idea by preparing a few legal terms and conditions before sharing your ideas and working with an outsource developer.

Typically, an outsourcing agency can provide all the legal documents, provisions, and terms for a typical software development project. However, a freelance developer won’t have these legal items to provide, so your lawyer will be providing them. Alternatively, if your freelancer is using a freelance platform (e.g., Fiverr, Upwork, etc.), then the platform will supply them.

Non-Disclosure Agreement (NDA)

An NDA is important for ensuring that the receiving party keeps anything shared with them as confidential information. This means that the receiving party is only using/sharing this information within context of your project.

💡We recommend that you sign a mutual NDA with your outsource developer before sharing any confidential information.

Master Services Agreement (MSA)

This is your contract with the outsource developer agreeing on the terms and conditions of your engagement. For app development, the following areas are important to consider:

Rights, Copyright, & Trademark: The developer shouldn’t use any intellectual property in your app that it doesn’t have the explicit rights or permissions to. This includes any logos, registered trademarks, trade names, images, videos, animations, and even text. If the developer uses any intellectual property in your app, then ensure that the developer assigns or transfers the intellectual property to you so that you also have the same permission or rights. Note that the developer must also have the rights or permissions to make such a transfer to you.
License: Ensuring that after receiving the app, you have unrestricted rights to do whatever you want with it. This means you should have a non-exclusive, royalty-free, transferrable, and sublicensable rights to your own app. This could only be an issue if the developer uses their own proprietary platform or technology, thus they cannot give you the rights to said platform.
Intellectual Property: The developer may create a new technology, algorithm, or functionality in order to meet your requirements. This is intellectual property. The developer usually retains this intellectual property, but will assign you the rights to use this technology.
Deliverables: Ensure that you identify all desired deliverables during the transfer of ownership. This will include the source code to your app, accounts to cloud services used by the app, and all acquired third-party software licenses required by the app. We cover this topic with more detail in the Transfer of Ownership part of this guide.
Cost Estimate: The developer will provide you with a cost estimate for the project. The costs should include a detailed breakdown so that you understand what you’re paying for. You’re going to use this information to add/remove certain requirements from your app in order to control costs. In the cost breakdown, separate code development costs versus on-going operating costs.
Deposit & Payment Schedule: Developers typically ask for a percentage of the cost deposit up-front (e.g., 25-50%) to secure your project. In addition, incremental payments are due upon each milestone completion and app delivery. We recommend against paying for the entire cost of the app up-front.
Third-Party Licenses: Are third-party licenses or service included in the project? The developer should explicitly clarify all excluded third-party licenses. You’ll need to acquire these licenses on your own when the app goes live.
Warranty: Ensure that have a warranty period (usually 30 business days) to identify and fix any issues found with the app. Your user acceptance testing finds most issues, but end-user testing will find the rest. You’ll want to fix urgent issues quickly before your app gains more users.

End-User License Agreement (EULA)

Regardless whether your app is presenting or collecting data, there are a variety of laws that may apply to your app centered around the data itself. Check whether these laws apply to your app (see “Check Applicable Laws” section above). The user must consent to the terms & condition of the app before collecting or using certain data (e.g., user registration, biometric, tracking).

💡We recommend discussing with your legal counsel on information to document in the EULA as it relates to the following:

Cookie Policy
Privacy Policy
Use of Biometric Identification

Part C: Sourcing a Developer

Finally, it is time to find your outsource developer. There are several items you could review to determine the suitability of a developer for your app project.

Agency: If you have a large project, you may need an agency with a team of people with various skills such as project managers, application architects, UI/UX designers, developers, testers, and technical writers (for documentation).
Freelancer: If your project is small, a freelancer might be more than sufficient to handle some of the required work, while you contribute with the remaining work.
Portfolio: Review the portfolio of your developer to see other similar works, review their designs, and understand their ability to develop apps of similar size or complexity.
Style Guide: The developer’s style guide accompanies the portfolio and gives you an idea of how the developer standardizes design so that the app looks consistent throughout. If there is no style guide, you may notice cosmetic issues such as inconsistent fonts, font sizes, colors, spacing, placement borders, etc.
References: Live testimonials from previous clients could also help you understand their working relationship with clients, how they work on a project, and the overall satisfaction of working with this developer.
Org. Structure: For larger projects done with an agency, you may want to understand the team’s organization structure and qualifications. This helps you understand who the key stakeholders are and how to handle escalations. This is also a good way to understand whether the agency is mature and organized.
Quality System: Inspect the developer’s procedures for the software development lifecycle, including training, coding standards, code reviews, testing, and documentation. This step is necessary if there are regulations or standards that apply to your app. The developer’s ISO certification is a great way to confirm the developer follows a quality system.

Part D: Locking the Technology Stack

A fully-functional app that satisfies all your requirements will need/rely on a variety of technologies. The more features your app provides, the more technologies it may use. Ultimately, the technology picked should be based on the popularity of the technology, which is critical for finding developers later for making future changes to your app.

Frontend Stack: This refers to the graphical side of the app that users will be touching and interacting with. The frontend technologies available are Angular, Ionic, React Native, Vue, PHP, JSP, ASP.NET, or vanilla HTML/JavaScript. 💡We recommend a frontend stack that is Angular framework and Ionic mobile framework.
Backend Stack: This is the technology that works behind the scenes of the app to connect with the front end, handle data, and process business rules. 💡We recommend a backend stack that is based on NodeJS, Java, or .NET.
Cloud Stack: If you app will be using cloud-based technologies for the backend stack, we recommend Amazon’s AWS. Microsoft and Google also offer cloud services, but they are second and third in-terms of popularity.
Application Programming Interface: Also known as APIs, this refers to how an app talks to another app or system (i.e., the “protocol”). While you cannot control the API protocol used by other systems, you can control the API protocol of your own app. 💡We recommend REST over HTTPS. Other protocols include XML over HTTP/S, SOAP, or web sockets.
Storage: If your app is handling data, it needs a location to store the data. There is no easy recommendation here because it depends on the type and volume of data. 💡We recommend you ask your developer for a variety of storage options and review the pros/cons of each option.

Part E: Using Project Tools

Your team will likely use some specialized tools to manage the entire software development lifecycle of your app. The list below highlights the “jobs-to-be-done” and the “go-to” tools that are popular in the market today.

Design/Wireframes: App Composer is a free rapid prototyping tool that is ideal for non-professional designers to create designs in minutes using drag & drop. Figma is a more advanced tool professional designers use, but it has a steep learning curve.
Process Flows: Diagrams.net is free and has all the features needed.
Decision Trees: Diagrams.net is free and has all the features needed.
Project Management: Github offers a free account to capture and manage project tasks. Jira or Asana are freemium tools that are also popular with larger agencies.
Document Collaboration: Google Drive is free to store, share, and manage documents. In larger teams, avoid passing documents via email because it is easy to accidentally use an older revision of a document. This can cause confusion, mistakes, and ultimately delays. A central collaboration location ensures everybody knows to find the most current documents they need. Other paid collaboration tools include Dropbox and SharePoint.
Document Creation: Github using markdown format is a standardized way to document both technical and user documentation. Keeping it in Github ensures you have revision control of the document. Alternatively, there is also Google Docs and Microsoft Word.
⭐️ Change Tracking: Github for creating a ticket every time you need changes to the app. Changes are either a new feature idea or bugs. Change tracking is also an important project management tool to prioritize what a developer should work on for the next milestone (e.g., a sprint). This is probably one of the most important tool for tracking the progress (e.g., % completion) of your project. We recommend tracking every requirement as a change at the start of the project; this becomes your feature backlog. Larger agencies also use Jira for change tracking.
Source Code Repository: Github for storing all the source code that a developer creates. Source code are simply text files … hundreds of them. But it is important to keep these files into a source code repository in an organized manner, especially for collaboration with multiple coders. Revision history will also ensure that if a change does not work, the developer can rollback the changes to a previous revision easily.
CI/CD Pipeline: Continuous Integration (CI) and Continuous Delivery (CD) is an automatic way to compile the source code into a working app. Setting up the CI/CD pipeline means never having to wait for the developer to deploy the app for you to test. Commonly used CI/CD tools include GitLab, Jenkins, or AWS CodePipeline.
App Installation: TestFlight (for Apple/iOS apps ony) is for installing the app on an iPhone or iPad so that users can test on real devices. Google Play Console Beta Apps is for Android only.
Apple Macbook: Developers need a Macbook computer to compile and create an iOS app (IPA file) so for submission to the app store. There are alternative methods that doesn’t require an Apple system, but this is Apple’s official way.

At the end of the project, you will want access to these tools (if used for your project) and the data contained within them. So talk to your developer about whether they provide the tools for your project or whether you’ll provision them (under your account) for the developer to use for your project.

Part F: Software Development Process

As your app development project kicks off, the project team will go through the following stages of development.

Business Analysis: For identifying business needs and determining solutions. Did a good job articulating your concept? Then, you can skip this step.
- User Stories: Identifies a user persona, indicates what the user is trying to do, and the user’s goal.
- Acceptance Criteria: What user testing conditions must work before accepting and closing the user story.
Project Management: Brainstorming and creating a list of “jobs-to-be-done” for the entire project. Capture this information in the project management tool as tasks with owners, due dates, and priorities. Some tasks have lead times, so ensure you add start dates to these tasks as well.
Agile/Scrum: An iterative development methodology that breaks down the project into smaller miletones (“sprints”). You should expect that the end of a sprint delivers the features in scope for the sprint. Include the following ceremonies into your app’s development methodology:
- Daily Scrums: Quick meeting every morning with the whole team to essentially understand if there are any roadblocks or obstacles to remove.
- Backlog Grooming: A regular meeting where the team discusses, reviews, and prioritizes the items to work on. This usually involves a smaller “product” team, rather than the whole team.
- Sprint Planning: A meeting before the start of a sprint to select items to work on for the sprint.
- Development: Team members will spend the entire sprint (usually 1-2 weeks) to work on the items prioritized in the sprint planning. We advise against sprints longer than 2 weeks as too many days would pass before you can review progress and pivot.
- Sprint Review: Team members present what they accomplished during a sprint. Usually this is a demo of the features, but could also be a status update.
Preview Environment: Deploy the app to a location that you can access after each sprint milestone.
User Acceptance Testing: Testing the app features yourself to confirm that the developer is on the right track. If your user stories and acceptance criteria are correct, your user acceptance testing should pass.
Source Code Transfer: If you are not using your own source code repository, then ensuring that the developer delivers the source code to you after every milestone. This usually happens after milestone completion, acceptance, and payment.
App Store Test Submissions: Submitting the apps for review and approval mid-way through the project as a “pre-test” submission. This helps you check/fix any requirements or gaps for the submission process. If you wait too late, Apple or Google may force you to make software changes to comply with the App Store policies. This is also where you will need to provide icons, images, and descriptions that comply with the app store policies.

Part G: Documenting Your Software

Every product should have good documentation. This is helpful to understand app functionality, design, behaviour, and also aid future developers to understand and make changes to the app.

Design Specifications: The structure and assembly of the app and its inner sub-systems.
Software Architecture: Additional information on the structure of the app including subsystems, third-party dependencies, and network connectivity.
User Manual: Information on how to perform the desired functions within the app. This includes error codes that users may encounter under certain conditions.
Process Flows: The sequence, timing, and general flow when processing data.
Decision Trees: The business logic used to arrive at one result or another.
Entity-Relationship Diagram: The database structure used to store data.
Deployment Guide: Most apps will have a backend software. The deployment guide provides instructions for how to setup the backend system from scratch.

Part H: Transfer of Ownership

Throughout the development process, your developer will write code. Your app will also depend on third-party products, tools, or services that the developer will register, subscribe, or buy licenses for.

💡 We recommend you understand every required dependency for your app and receive all of this information during the transfer of ownership. Work with your developer to understand which dependencies can and which dependencies cannot transfer.

Source Code
Documentation
Software Keys (Google Maps, OneSignal, AWS, etc)
Third-Party Service Accounts
Software Licenses
API Tokens
Developer/App Store Accounts (Apple Developer, Google Play Console)
Intellectual Property

Transfer all of these back to you. If you have future app changes to make, you can engage the same developer or try a different developer at your discretion. Sometimes it’s better to obtain these dependencies by yourself and supply them to your developer so that they are in your control.

Conclusion

Well there you have it. Our complete guide for how to outsource your app development. We put this detailed guide together based on over 25+ years of app development (see About Us) as both an outsource developer and as a sourcing client. MSE understands that “I just need the app built” is more involved that converting an idea or wireframes to app. To do this well, it involves a structure and process to ensure you get what you want at the end of the project.

With that said, good luck with your app development project. If you have any questions or feedback, please add a comment below as we will answer your questions and update this guide. Thank you for reading.