RFP process – list of requirements
Companies decide to create or upgrade a mobile application when current solutions no longer meet business objectives and user needs. The dynamic development of mobile technologies, increasing customer demands for intuitiveness and performance of applications, and the need for integration with other company systems are just some of the reasons why investment in a modern application becomes a priority. The problem is often outdated technologies that limit scalability or the lack of advanced features such as content personalisation or offline support. Equally important is ensuring user data security and compliance with current regulations.
When developing a new mobile app, we are faced with the decision of choosing a framework for a specific project, such as Flutter, React Native or Swift, but most importantly, at a crucial step – choosing a company that will create an app that meets unique business requirements. It is the competence and experience of a given supplier that determines whether the application will be functional, efficient and ready for future technological challenges.
The majority of prepared requests for proposals for mobile app development describe the relevant criteria as standard, such as the scope of the project, delivery times or budget. However, there are some key elements, often overlooked at the RFP writing stage, that make it significantly easier for potential suppliers to prepare worthwhile bids. Here are five such points that should be included in a request for proposal for a mobile app development project.
1. Requirements filtering – what business problem is the new mobile app supposed to solve?
Rather than focusing solely on specific functionalities, it is useful to clearly define what less obvious needs the company wants to solve with the mobile app. This is crucial so that the supplier can design a solution that not only meets the functional requirements, but also directly supports the project goals.
Example:
‘Currently, users leave the purchasing process because of the complex interface. The new app is expected to shorten the purchase path to three clicks, increasing conversions by 20% within a year.’
2. Team structure & Division of responsibilities
Clarifying how the in-house team is set up and defining roles and responsibilities (in-house vs. supplier) is extremely helpful information. The IT partner can then predict exactly what resources will be needed and how best to plan the collaboration, taking into account the team’s remit.
Example:
‘The IT team will handle the integration of the application with in-house systems and the marketing team will provide visual and textual content. The supplier will be responsible for UX/UI design, development and testing.’
3. Past experience & Challenges
Describing the solutions currently in use and the team’s experience is key so that potential suppliers can better understand the specifics and requirements of the project, adapt their approach and avoid replicating previous mistakes. It is useful to include answers to the following questions in the tender enquiry:
What applications have we built to date?
It is useful to list the applications that the company has already developed or used and to indicate their main functionalities.
Example:
‘Previously, we had built a loyalty app for our customers that allowed them to collect points and redeem coupons at stationary outlets. However, the app was not integrated with our e-commerce, which limited its usability.’
What technologies do we have experience in?
It is important to indicate the technologies in which the company’s IT team has experience, which can facilitate the integration or subsequent maintenance of the application. The prepared request for proposal should include such information so that suppliers can tailor their proposals to the company’s internal capabilities.
Example:
‘Our IT team has experience working with Node.js and React technologies, which could be helpful in integrating the mobile app into our backend.’
💡 The choice between a native, hybrid or web-based solution depends on the specifics of the project, budget and user expectations. You can read more about this topic here: Mobile apps: native,hybrid or web?
Have we built a similar application?
If the company has previously carried out a project of a similar nature, it is worth highlighting this and describing what challenges were encountered and what could be done better.
Example:
‘In the past, we built a mobile app to support marketing activities, but it did not meet the performance requirements with high traffic. We want the new design to take this experience into account and address these issues.’
Additionally, it is useful to discuss the criteria for selecting suppliers to better understand the requirements and expectations of potential partners. Prioritising requirements and identifying so-called ‘deal breakers’ will help exclude unsuitable suppliers, simplify the process of selecting an IT partner and save time.
4. Application usage scenarios
Rather than being limited to describing purely technical requirements, such as expectations of the system, it is useful to include the key user paths being designed in the RFP. This allows providers to better understand how users will use the application in practice, which is crucial when designing the UX/UI and application architecture. Scenarios can be presented in the form of narrative, usage diagrams (e.g. user flow) or tables that detail key user actions in the application.
What can usage scenarios look like?
Scenario 1: Shopping on an e-commerce application
‘The user opens the app to browse new promotions. He selects products, adds them to the basket and then pays using the integrated payment system. The app automatically saves the user’s details for faster subsequent purchases.’
Scenario 2: Using offline applications
‘The user browses the offline product catalogue while travelling by plane. He or she can add products to favourites or a shopping cart, and when the internet connection is restored, the app synchronises the data with the server.’
Scenario 3: Customer service in a banking application
‘The user logs into the app and goes to the ‘Help’ section. He asks a question in live chat, where an AI bot suggests answers. If the problem is not resolved, the conversation is redirected to a consultant.’
Scenario 4: Push notifications in a loyalty programme
‘The app sends a notification of a new promotion, which encourages the user to open the app. The user browses the offer, uses accumulated loyalty points for a discount and completes the purchase.’
Scenario 5: Booking services in a fitness app
‘The user browses the available class times at their favourite fitness club, selects a convenient date and books a place. The app sends a notification reminding the user of the class one hour before it starts.’
💡 When designing usage scenarios, it is also worth considering the accessibility aspects of the mobile app so that it is user-friendly for all users – more on this here: Mobile app accessibility: how to make it accessible?
The role of the application in the architecture, expectations of the system and integration with other systems
An important element of the RFP (request for proposal) is to determine what role the mobile app will play in the company’s existing infrastructure and with which systems it is to integrate. The app can perform a variety of functions, such as being the central point of contact for customers, supporting internal processes such as order management, or acting as a tool for collecting and processing user data. Providing this information allows the supplier to understand how the application fits into the company’s overall technology strategy.
It is crucial to indicate the systems with which the application needs to integrate, such as CRM, ERP, analytics platforms or external APIs.
Example:
‘The app will pull real-time product availability data from the ERP or PIM system and synchronise customer data with our Salesforce CRM.’
These types of details are necessary for the supplier to design an effective architecture that takes into account existing technical constraints and business requirements.
The supplier needs to understand exactly where the application will get its data from, what processes it will support and what systems will be critical to its operation. Clearly defining these dependencies, for example through a description or a simple architecture diagram, minimises the risk of errors, facilitates work planning and ensures that the application is consistent with the existing infrastructure.
Before you choose an IT provider: ask the right questions
To avoid unexpected expenses and choose a partner who understands your organisation’s needs. Download the checklist of questions in PDF format 📧 and find out what questions to ask your IT provider to ensure their offering meets your needs and long-term goals.
Summary
A well-constructed request for proposal avoids prematurely excluding a bidder, simplifies the vendor selection process and manages the entire implementation process more efficiently. It is worth remembering that an RFP is not just a document – it requires the involvement of key stakeholders and the provision of thoughtful feedback at each stage.
Incorporating the above elements into the RFP increases the chances of selecting a vendor that meets the company’s detailed requirements and delivers a mobile app that is tailored to the users’ needs and the organisation’s strategy.
Author
Michał Łukawski
IT Client Partner
With more than 16 years of experience in the IT industry, Michał Łukawski supports corporate clients in creating and developing digital products that respond to real business needs. He served as Managing Director of SYZYGY Warsaw and was part of the team responsible for the organisation’s transformation to turquoise. His approach combines understanding business needs with building lasting relationships based on transparency and shared responsibility. Michał is an advocate of agile working methods and focuses on bringing products to market quickly and continuously improving their value.
Michał is also an author:
A good application is one that meets your business objectives
An RFP is a start, but the success of the app depends on how well it responds to the needs of your business and users. We build mobile apps that not only work, but bring real value – supporting sales, optimising processes and engaging customers.
Want to build an app that meets your expectations?
📩 Fill out the form – let’s talk about your project.
