The anatomy of an enquiry: How to write a RFP/RPQ which every software house will understand

Have you ever wondered what’s the deal with enquiries in software development? It’s high time someone tackled this issue!

Product-thinking vs. services-thinking

Why do people send enquiries? Of course, they want to find a company that is the best fit for their project. The final decision is based on many criteria but the price is obviously among the most important ones. Nowadays, most software houses work using agile methodologies (e.g. Scrum, Kanban), therefore, the final price depends on the time spent on development. Nevertheless, even when you’re working agile, you need some starting point – an estimated cost of developing the app.

In The Software House, we always try to prepare such estimations as fast as we can – usually in a few days. Other software houses do likewise. We don’t ask for details because we know that at this stage they’re not 100% certain (even if some clients believe that everything’s clear). We start to think about the application as if it was our own project: we develop a vision based on what the client has told us and on our experience, our know-how from previous projects.

At this point, we’re not yet to be treated as a provider of a final app – you should rather think of us as a technological partner, a software advisor.

Software houses don’t sell products – we provide services which lead to the creation of an application.

As a client and an inventor, you need to tell us WHAT you want to achieve. We, as a software house, need to tell you HOW to do it. And then, if you like the plan, do it for you.

Great minds (should) think alike

In order to present the most accurate project estimations, we need to have the same understanding of the whole idea. Many clients believe that the only way to achieve that is to prepare a very detailed list of the app’s functionalities. In fact, it’s quite the opposite.

Many enquiries which I receive every day are OVERDETAILED.

Every description like this is subjective, modified by individual bias. For example, you can write a fifty-pages-long enquiry but you’ll probably still omit a few very important facts. For example, because they’re obvious to you (while not necessary for the software house). On the other hand, we have the knowledge and experience which is probably not common in your sector (all in all, this is the exact reason why you contacted us in the first place).

In the end, it’s crucial that everyone knows their part – you’re the business guru, we’re the software experts. You shouldn’t spend hours thinking about how the app should look like and explaining to us which buttons should be there in the menu. What we really need to understand is your business: how you make money, who are your clients, what are the most important business risks, what makes your company stand out etc. Then you need to explain why exactly you came up with the idea of an app, what problem are we gonna deal with, what opportunities you want to grasp.

The next step is thinking about the users.

Try to imagine who’ll be using your application and what are the needs of these people.

Usually, you know it straight away but sometimes even such basics aren’t clear at the early stages. If it’s true in your case, simply write about it in your enquiry. Fortunately, nowadays, the best software houses are equipped with great tools – they can, for example, conduct user interviews (e.g. during the pre-development workshops) to gather the needed info for you. Such data is not only a nice thing to have. It’s a necessity.

Finally, it’s time to think about the functionalities. Not earlier, not at the beginning of the process. First – it’s the business. Then – the users. Functionalities come in the end. And do you need to write them down using technical language? Nope! A great way of doing it is to prepare so-called user stories: “as a user, I want to log in using my Facebook account”, “as a user I want to change my profile photo”, “as a user I want to save the invoice as a PDF file” etc. And if you’re not familiar with user stories, you can explain functionalities using everyday language as well.

No need to spend time thinking about some magical software-developish mumbo jumbo – it’s your business that matters! Let the developers take care of the development.

On the other hand, if you’re tech-savvy and want to develop the app using certain languages or frameworks, don’t forget to mention it! Technology stack compatibility is very important. The same goes for choosing the platform: do you need a web application, a mobile app, or both? If you’d like to go mobile, do you have any preferences regarding the operating system (iOS/Android)? And, last but not least, do you know of any software products which are already there on the market and are based on an idea similar to yours? If you’re not really sure that you can answer all those questions, don’t worry – a good software house should advise you on this matter. Why? Because you’ve already explained your business idea at the beginning of the enquiry!

What’s in it for me?

When you’ve told us about your whole idea and we’re on the same page, then we can really talk about the budget.

The budget vs services

As I stated before, software houses don’t offer a product with a price tag on it but rather provide services. However, we need to know your budget because we need to know your level of expectations.

When we take the whole business idea and the amount of money that you can spend (along with the deadlines), we can come up with a proposal for a software solution that will meet your expectations and let us stick to the budget at the same time. Therefore, don’t forget to define your budget in the enquiry.

Understanding the business context is key

But remember – the business idea comes first. Without full understanding, we cannot prepare accurate estimates.

Is this really the best approach? What are the benefits of thinking about the enquiry in the way presented above?

First and foremost, you make sure that the software house focuses on the things which are the most important in their job: creative approach and technical know-how. If you let us fully understand your business, then you don’t need to worry that you forget to tell us about something. We’ll very quickly realize it on our own.

Instead of getting stuck with developers that you need to babysit on every step of the process, you hire technological partners delivering the real value.

The ultimate guide to writing an enquiry

I believe that the best way of summing everything up is to provide you with a handy checklist. Try to follow these steps when preparing your next enquiry:

1. Always start with describing your business: what services/products do you offer, who are your clients, how do you make money
2. Then explain why you need a custom software solution, what problem you wanna solve, or what opportunity you want to seize
3. Think about the users of your future app – who’ll use it and what do these people need
4. When you know something about your users, it’s time to enumerate the most important functionalities (and please, don’t make the list over-detailed)
5. Is technology important to you? Do you want the app to be developed using a certain language or framework? Why? Do you need a web app, a mobile app (iOS? Android?) or both?
6. Prepare the so-called benchmark, i.e. tell us if you know about any applications on the market which are similar to the one which you’re planning to build
7. Write about your budget, being as honest as you can be – the more accurate the budget info, the lesser the risk of wasting time (on both sides)
8. Speaking of time: are there any deadlines? When do you finish gathering proposals? And – even more important – when do you want your app to be ready? Why so?

Trust me: the software houses which will receive your email will be grateful. What’s even more important, they will come back to you with great, self-explanatory proposals. Why? Because their vision won’t be based on guesses – it will be based on your very own business idea.