‘I need a website that will bring $10 a day’ — we got this request long before our MVP development agency was founded. At that time, our PURRbosses, Alexander and Anton, worked as freelancers. There were no other details. And, you know, sometimes such a request is better than a 75-pages technical requirement.
Let’s talk about how to write a stunning app development RFP and make sure that the person who receives it clearly understands your needs and converts them all into something applicable and useful.
WHAT and WHY instead of HOW
When product owners cherish the app concept for a long time and carefully think through its usage scenarios, the entire business idea may seem stupidly obvious. Series of discussions with family and friends made the product scroll back-and-forth in your head for a hundred times, and it has already acquired a clear outline. So, when it comes to contacting the development company, product owners tend to skip the whole-picture level and go straight into details i.e features that are to give enough context. In fact, they won’t.
Once we got such an app development RFP:
HOW and even WHAT are clear. What about WHY?
Seems that the client provided tons of details in his app development RFP: about the planned functionality (text sending, moderation) and colors. But wait a minute, do you understand what this is all for? What are the user scenarios? Why does the user want to send a message? For what purpose should the text be displayed on the board and for whom? And what kind of board it will be: scoreboard at a football match, a news ticker on a bank wall or a digital billboard near a bus stop?
In fact, features and colors do not help to answer the most important questions: what kind of product do you need? Why do your targets and business actually need it? Without seeing the whole picture (not just a list of features and requirements given in vacuum), there’s no way a software development agency will give you an accurate project estimation.
Usage scenarios (WHAT & WHY) > Desired features and colors (HOW)
How to describe HOWs
If you’re dead sure about what your future product is going to be and you really yearn to describe HOWs, the ideal way to write a working app development RFP is referring to other products or competitors.
I want a virtual card as in PayPal. Filter mechanics as in Amazon. Booking as in AirBnB and HeadSpace-like design
When it comes to writing app development RFPs, feature requirements are important yet not critical. It is critical to convey a business task — as in the original example with that ‘$10 per day’ project. It is unlikely that someone will deliver a fully-functioning product based solely on one requirement (there might be exceptions, though). This example is exaggerated yet very illustrative — because it provides a clear business goal.
As for functionality, any software development company can provide guidance on this matter. Of course, only after you share business goals, limitations, and pain points that the product is expected to cover.
Technical Requirements aren’t must-have
Sometimes we receive app development RFPs with 40+ pages of detailed requirements for literally everything: ergonomics, technical aesthetics, data protection, etc. Such documents happen to be absolutely ineffective — lots of requirements and zero context.
Therefore, there’s no need to get started with a Technical Requirement Specification, describing how the devs should develop your app. Instead, it’s better to provide the product manager with something that answers the question ‘Why and for whom do we build this app?’ It may be called a Business Requirements Document (BRD). Would be perfect if you can keep it within 2 pages.
Technical specification might be helpful for accounting — for instance, to confirm the costs of hiring a software development team. In this scenario, we can deliver such a document after launching the work process (for example, at the design stage). Although, a little bird told me that some companies are ready to sign such specifications on an ex post facto basis (which is, by the way, pretty okay :D).
Business requirements first, then technical requirements
About money
Most clients dread the thought of disclosing the budget as they expect confrontation and cheating — ‘I’ll tell you how much money I have and you’ll charge a higher price!’ At a flea market, it might be a working option. In the world of development, things are a little bit more complicated.
How to save time when choosing a contractor? Frankly share your budget expectations right from the start — in the very first letter. This approach has two heavy advantages:
- If the studio works in a different price segment → you’ll save time on emails and phone calls and find a suitable contractor faster,
- The manager will certainly offer you an option that fits the expected budget.
Whatever one may say, software development is not only about technical skills but also about creativity. Any feature can be implemented in various ways. Let’s say, you want to integrate real-time chat functionality into the application. This feature can be estimated in different ways:
- Spiced-up: with the ability to track when a person is typing or when the message is read; set dates and delete/edit messages.
- Basics only: just a real-time chat, which, nevertheless, fulfills its main purpose.
Left: All-packed chat. Right: A chat where you can only receive and send messages
The same rule also applies to design: the budget size defines the complexity of animations, transitions, and custom illustrations.
Not understanding how much development costs, walking around the market and checking the prices is normal. Here is a real-life example:
Once I searched for a place to print a book. I needed just one copy and had no clue about the prices in this market: assumed that the services could cost from $50 to $300. My decision was to stick to $100. To exclude $300 offers at once, I indicated the budget in a letter and sent it to local printing houses. As a result, I gathered a short-list of guys who could do the work within my initially-set budget: some suggested replacing a hard cover with a soft one, others advised a cheaper paper. Expectations of costs were justified, and the task was completed.
Printing a book or developing a business idea — you always understand how much money you’re willing to invest in this. Simply share your price expectations when writing a software development RFP. With this knowledge, the agency will offer you the optimal ‘cover hardness’ for your future product.
Discussing budget is a collaboration, not a confrontation
I have a filled brief, will it work?
Agencies usually offer to fill out a brief. In fact, the practice is good: filling out the questionnaire, clients can sort out the project for themselves. For example, it can make you think about some project aspects that might be missed earlier. Maybe you need offline mode? Have all the user roles been taken into account: admin, maybe a moderator, or a separate interface for the support manager?
Basically, filling out briefs is useful. But re-sending a brief filled out for one agency to another is definitely not a good idea. One of our clients made this mistake once.
In the first letter, the client sent us a brief, which he had previously filled out for another studio. The client needed a functional web application like Airbnb. The agency which gave him that brief, specialized in simple multi-page websites. So, what did we get? Description of the project with a ton of notes on the color scheme, page layout and flash animations.
A bunch of requirements that have nothing to do with business objectives 🙁
In the future, we’ll certainly need colors. Although at the current moment there are more significant things that should be considered first in order to provide you with an estimation: user flow, server logic, integrations. So, without having a good understanding of the entire product idea and its business logic we shouldn’t even start discussing ‘unnecessary’ stuff like page layout.
This would be as stupid as planning to buy a swimsuit for a vacation on a ‘future’ job’s salary
Therefore, a brief that you filled out for one agency isn’t what can help a manager from another agency get back to you with an actionable answer. It might be helpful ONLY for the agency who asked you to fill out this. In the story above, it’s the agency specializing in landing pages — unfortunately, a landing page is absolutely not what the client expected to get in the end.
Even if you plan to send a brief to an agency of the same profile, there’s a chance that this agency may follow different working approaches or have absolutely different specialization. OR that the brief itself is poorly composed. For all these cases, a simple Google Doc with the project description would be even more helpful, seriously 🙂
Be ready for calls
‘I’ve created a clear and well-structured app development RFP, but the agency still wants to have a call’
Suppose you’ve already done all the above-listed. Clearly described the concept of the future product, shared budget expectations. In case these steps are already done, you have already saved a lot of time on calls and meetings + made the manager fall in love with you 🙂
At Purrweb, we firmly believe that communication should be treated as an investment in the project. Even when you start searching for a suitable project team — it’s crucial to invest time in communication. Just one thing for you to think about: without being ready to devote a couple of hours a day to communicate with potential contractors, how will you find the time and the energy for the rest?
We have already discussed large Technical Specifications that are usually attached to the application letters. To be honest, agency managers won’t invest time into parsing 38 pages until they get in touch with you personally.
Without an actual call, agencies are unlikely to take such an application into assessment right away.
I understand that repeating the same thing to 6 different agencies is tiring. Although at this stage, your primary goal is to understand how easy it is to communicate with a potential project team, if you’re on the same wavelength about working processes. It is absolutely fine when local shop cashiers irritate you with just how they look. But the development studio is your long-term partner, so it’s crucial to filter out anyone you don’t like in terms of communication. Having a live chat (a voice call or, what’s even better, a video call) is the easiest way to get clarity about this.
In application, share your contact info, the time when you are available for a call, and a convenient communication channel
Real people — real language
Last but not least. When I chat with friends on Telegram, our communication skills always on top: we write EXACTLY what we mean, use plain words. When it comes to business talks, the way we talk to each other drastically changes: a sense of simplicity disappears, all phrases and texts become messy and super complicated.
‘Messy and super complicated’ is when you read the text twice and still didn’t get anything
Hiding the context behind too long, complicated words is not the key to efficient cooperation. This is superfluous tinsel, which will prevent the team from getting the essence and understanding how to help you out. How to avoid this? Just talk in plain simple words — from day one. You perfectly do this at home and in the office. I bet the future project can be discussed in absolutely the same way.
