2020 heightened the need to digitize workflows and streamline communications. As organizations embrace “anywhere operations,” companies are investing in custom mobile technologies to support employees and customers wherever they are and are often in need of a mobile development team to work alongside their existing team.
The search for a development partner commonly falls in the hands of a non-technical individual like a CMO or project manager. Many organizations require this process to start with a request for proposal (RFP) to compare costs and capabilities.
Writing a mobile app RFP, however, can be overwhelming for someone who doesn’t work in tech every day, and comparing development teams can feel a bit like comparing apples and oranges. If you choose the wrong partner, your product may not provide the return on investment you were hoping for, bringing you back to square one (but a few hundred thousand dollars lighter).
This article will outline what should be included in your mobile app RFP and what responses to expect from development teams.
How to Write a Mobile App RFP
In your RFP, there are critical pieces of information you need to convey in order to generate interest from the best service providers.
Company Information & Project Summary
Here is where you’ll give a brief bio about your company and the problem you’re looking to solve using mobile technology, clearly outlining in as much detail as possible:
- Features you want in your app (e.g., push notifications, mapping, etc.)
- Data the app will work with and where that data currently lives
- Platforms and operating systems you anticipate your app will need to support
- Vision for how users will interact with your app
- User demographics: internal (employees), external (customers), or both
- External tools the app needs to work with (e.g., SalesForce, an internal CMS, Facebook)
- Overall success criteria (e.g., number of downloads, increase in sales)
Outlining these scopes of work will help your business partner set expectations for your services partner.
Providing your budget allocation in an RFP helps a tech agency determine where you can get the most value with the least amount of effort. When they know your budget limitations, they can help you prioritize which features and platforms your product can support now and which may need to wait.
Clearly identify when you want looking to get started and articulate any internal deadlines you have as part of the app launch. Building an app can take a long time: Clarifying your timeline for vendors will help them level with you about expectations.
Proposal Due Date and Contact Details
You want to give a potential partner adequate time to do their due diligence to research and understand your problem in order to create the best approach to building technology that solves it.
We suggest having a period of 2-3 weeks for getting questions submitted, and then another 2-3 weeks after that is when as a deadline for the RFP. Make sure also to outline who the best person is to contact within your organization for questions on the RFP
What to Expect In An App Proposal
An RFP essentially provides a rough description of the task that needs to be accomplished and demands a fixed cost with a slim margin of error. It's a challenging mandate to place on developers.
The true value of an RFP lies in the opportunity to learn how a team’s experience relates to your project, how well they communicate, and how they solve problems as they arise (because they’re bound to).
At The Jed Mahonis Group, we’ve filled out many mobile app RFPs, and we never go into them blindly. Exploratory discussions tell us from the onset if a project is a good fit for our experience or whether we’d recommend someone else in our network with a different skillset, so before a company fills out your RFP, it’s important to have preliminary discussions about your project.
Filling out an RFP is a lot of work for all parties involved. Having rudimentary conversations with potential vendors will make sure their responses are catered to your needs and not a copy and paste from the last RFP they filled out.
In an executive summary, a developer company should describe how its service offerings have the capacity to fulfill your project’s needs.
Where do their weaknesses lie and who will they lean on for this? What will the team look like that will be handling your project?
Description of Development Approach
Do you remember in math class when your teacher insisted you show your work? It’s because you can arrive at the answer to a math problem in different ways. While you might use one formula to get the answer, another person might know of a more efficient formula or take a totally different path.
Building software is a lot like that. At the end of the day, any competent dev shop is going to deliver an app. How they arrive at that end result is just as important.
A tech partner should be able to plainly describe to you their approach to app development so that even the most technically inept on your team can understand the process. Like showing your work on a math problem, good dev shops have faced these problems time and time again, so they should be proud to share how they get it done.
Description of Proposed Deliverables
It’s important to clear up any ambiguity about the work you’ll receive. This is their opportunity to share how they understand your problem and what a successful project will look like by explaining how they’ll achieve the success metrics outlined in your executive summary.
We typically provide a project design document outlining the strategy for the first round of work, along with descriptions of the tools being built (frontend or backend).
Timeline and Budget
There are many ways to bill for app development services, and regardless if billing is done based on time and materials, a monthly retainer, or a flat project fee, an experienced tech team should be able to provide full transparency of when certain tasks will be completed along with where your budget is allocated for each task.
Here is how a proposed project timeline could look:
For the effort described above, an estimate of resources to successfully complete the project might look like this (based on time and materials billing):
Along with the timeline and budget breakdown, they should also include details for any ongoing expenses and payment terms.
Portfolio of Similar Projects
This isn’t a place for companies to brag about their accomplishments, but for them to show how their work corresponds directly with your company’s needs. Have they done a project in your industry before? Have they worked on an app with similar requirements?
While case studies are good, a detailed description of how their work on a comparable project correlates to your exact needs can give you confidence for making a decision about which app developer to partner with.
Many agencies look good on paper, so speaking with former or current clients, hearing what they say (and don’t say) about an agency, can be a good indicator of how their team operates.
Ideally, their reference list would include someone from a project listed in their portfolio section earlier.
Project Management Strategy
Review the proposal to determine what tools developers use to communicate a project’s status and how they manage project details such as new features and bug reports.
Risks and Mitigation Strategies
App development is often a long endeavor, and it’s no secret that developers are in high demand. Odds are high the tech team you choose to work with has multiple projects going on at the same time as yours, so it’s important to set clear expectations to mitigate risks, like a breakdown in communication (typically the number one reason a project fails).
Other common risks include agency stability, how confident they are in delivering what they promise, how close they can stick to a timeline, and what happens if the project goes over budget.
How Long the Proposal Is Valid
Finally, the company should provide the window of time their proposal is valid. This is typically between 30-90 days.
While an RFP is often an internal requirement for many companies to get started on a project, we don’t suggest sending out hundreds of them unless you want a bunch of garbage to sort through in return.
Leverage Your Network and Use Templates for Writing an RFP and Evaluating Proposals
Whether you're building a mobile solution from scratch or need a new development team to pick up where another left off, you’ll pay dividends by speaking with at least 3 potential partners (start by asking your network for recommendations) before asking them to fill out your RFP.
Better yet, you might want to reach out to a few shops before crafting the RFP to see if they can help shape the proposal in a way that will help you get the project through your internal red tape.
Writing an RFP for a custom mobile app can be tough the first time you do it. Following these tips will help make sure you find a partner who can knock your mobile app project out of the park!