It’s no secret that consumers today are prioritizing ease and accessibility more than ever. In the Age of Information, interactions with business have been streamlined, integrated, and simplified– being a consumer has never been so effortless. At the very center of this process is the app space– a market that has exploded in the past decade. But how are businesses supposed to capitalize on this trend? What are the details of kickstarting your app development?

The very first step for most companies will be engaging with potential vendors for partnership in app development. And that means issuing an RFI, RFP, or RFQ– a detailed document that informs vendors of what you’re looking for in a potential partnership. For businesses who have never issued an RFP, this process can be mystifying and stressful. What should an RFP include? What should it avoid? What does the process of engaging with vendors look like?

If you’re finding yourself asking these questions– don’t worry! RFPs can be tricky, but once you have the basics down, the process can proceed smoothly and without stress. Read on to learn how to structure your RFP and how to avoid the common pitfalls of producing them.

Where to Start

Once you’ve decided to move forward with developing an app for your business, you’ll have to choose from a few types of documents to prepare and send out to vendors. The type of document you choose will be based on the level of detail that you’ve already established for your project, as well your existing experience and expertise in the app development arena.

RFI (Request for Information)

An RFI, or Request for Information, is the least detailed document that you would need to prepare. Intended to spark creativity and solutions from vendors, an RFI should include a brief description of your business and an overview of the problem that your new app is intended to solve. In return, interested vendors are expected to send information about their products and services, and may send broad ideas about how they are uniquely situated to develop a tech solution to the business problem your app is intended to solve. This path is great for businesses who have committed to developing an app but haven’t yet decided on many of the details. An RFI is also helpful for companies that haven’t developed apps before or who do not have technical expertise in the app arena because much of the work in narrowing down specifications and details are transferred to vendors.

RFP (Request for Proposals)

An RFP, or Request for Proposals, contains a great deal more detail than an RFI. We’ll focus more on RFPs specifically below, but RFPs need to contain the same components as an RFI as well as functionality requirements, metrics of success, a detailed budget and timeline, and more. This is a great option if you already have a plan or vision for your app and are ready to start developing to your own specifications quickly.

RFQ (Request for Quotation)

An RFQ, or Request for Quotation, is probably the most detailed out of the three documents. An RFQ, or an Invitation for Bid (IFB), is intended to inform vendors of your exact product specifications. All vendors will return from this document with exact pricing, as every detail of development will already be laid out by you, the inquiring business.

Businesses vary widely on their level of experience with and expertise in the app space. However, most businesses are not totally without technical resources; the explosion of the app space in the past decade, as well as the development of the Information Age, has required companies to learn to keep up with the wildly increased pace of technology development. To that end, we will be focusing on the middle of the spectrum in technical knowledge– RFPs.

What is an RFP?

An RFP, or Request for Proposals, is a document that your company will prepare in the early stages of developing an app with a vendor. The purpose of an RFP is to connect you with a vendor that can produce an excellent product within your timeline, budget, and vision. To find that perfect match, you’ll send out RFPs to multiple vendors, and if your project fits within a vendors’ scope, expertise, and pricing, you’ll get multiple proposals in return. Ideally, you’ll then select a vendor to work with you on your app development and establish a mutually beneficial working relationship within the timeline of your project.

Common Misconceptions about RFPs

Many businesses make the mistake of using RFPs as bidding tools. These companies might withhold budget information or important functional aspects of their potential apps in an attempt to engage more vendors and create a bidding war. The effect of this strategy, however, is the exact opposite. Consequences of leaving out important information in your RFP include, but are not limited to:

Waste of time and resources

Ultimately, what you’re looking for in an RFP is a match– a vendor that has the time, resources, and interest in completing your project within your budget and timeline. By withholding budget information, you risk progressing with a project that will never get off the ground– having meetings with vendors that are out of your budget range, moving forward with project development in accordance with their proposal ideas, and turning down other offers that may be more within your budget– all to realize that your selected vendor is not willing or able to complete your project within a realistic budget. You’ll then have to start your search over from the beginning, improving your RFP with the detailed budget and timeline information that should have been included in the first place.

Matching with a company that isn’t right for your project

The problem of vendor-matching isn’t just financial. Vendors know their areas of expertise well, and often are focused on cultivating a portfolio that showcases them. If your RFP is not sufficiently detailed, you might end up with a vendor that doesn’t specialize in your app type or field– or worse, get turned down by the vendor later in the process.

Fewer responses

Finally, submitting an intentionally vague RFP might decrease the number of responses. There are two reasons for this phenomenon; first, it is possible that vendors will see through your attempt to start a bidding war and decide not to participate. Vendors do not often appreciate this tactic and may choose not only to not reply to your RFP, but to not respond to RFPs from you in the future. It is also possible that vendors are simply looking for information on which to determine your compatibility– namely, budget, timeline, and functionality details. Omitting this information decreases the likelihood that vendors will see potential in your project and respond with a proposal.

How to Submit a Great RFP

So, we’ve talked about what not to do in an RFP. But what should you include? How detailed do you need to be? In this section, we’ll give a sketch of what a successful RFP might look like.

Executive Summary

Open your RFP with an executive summary. This section should include a brief description of your company, the problem that your proposed app is looking to solve, and some details of the solution you’re looking for. Keep this section punchy and to the point for highest impact.

Company Overview

The first thing vendors want to know is who is sending this RFP. You’ll want to provide a more detailed overview of your business, including important stakeholders, leadership contacts, business objectives, target market, and anything else you’d like your potential vendors to know before they dive into your project overview.

Project Overview

The next section entails a more detailed description of your project. First, restart the problem that your proposed app is intended to solve. Then, sketch out some details of your proposed solution. This section should include the target users, existing competition, intended platforms, potential barriers, scope, and references for style and function.

Functionality Requirements

Following the project overview, you should provide vendors with as detailed a list of functionality requirements as possible. What features are non-negotiable? Which are optional? What other app solutions exist that address your business problem? Which features must be included for the first release, and which can be updated later?  If you have a prototype, include it here. Most importantly, the more detailed this section is, the better; vendors will have more information to work with when presenting proposals and deciding whether the scope of your project is within their area(s) of expertise.

Goals and measurement criteria

It’s not enough to simply present what you think will work for your app– you need quantifiable measurements of success. What do you want your app to look like three months down the line? Six months? Three years? How do you project the usership of your app to grow and change in this timeline? You will want to let your vendors know your goals and projections in advance.

Timeline

One of the most important sections of an RFP is the timeline. As always, you will need to be as detailed as possible here. If you can, include the issue date of the RFP, deadlines for vendor questions, deadlines for proposal submissions, final vendor selections, and more. You’ll also want to set dates for post-selection: project deadlines, launch dates, and any other important milestones for your project.

Budget

Budget will depend on the scope of your project. How many platforms are you planning on using? How many users? How many and how complex will the features be? The name of the game in the budget section is detail; you should include a defined range for your budget, and any external factors that might influence it post-vendor selection. Ultimately, you want a great match between your budget and your vendor’s pricing, so be transparent here.

Post-RFP

After a considerable amount of research, you’ll submit your RFP to a variety of vendors that you’ve determined might be a good match for your project. According to the timeline you’ve included in your RFP, vendors will get back to you with questions, calls, and submissions. Based on your responses, you will select a vendor that best matches your needs for your project, and you will on your way to burst into the app space with a phenomenal technology solution that will work for you, your vendors, and your users. As long as you’ve followed the guidelines we’ve set out here and prioritized detail and transparency, the RFP process should be only the first step of a long and exciting journey to your app launch and your thriving addition to the exploding app

Receive Weekly Insights from PC40