Before you start: what to discuss with your software development agency

Finding a software development agency is not rocket science. Choosing the right one? Definitely is, though. Before selecting a particular IT company for your project, it is important that you verify it back and forth. Although a thorough examination of their portfolio, skills, and expertise is essential, you also need to assess their approach to your project and business. 

Every software development agency that takes your project seriously will ask questions throughout the project to fully understand what it takes. The more prepared you are for answering them, the stronger your ability will be to take your project to new levels with the right team and attitude. 

Here we will go through the most common terms, methods, and questions you need to consider when collaborating with your software development partner. TL;DR, we’ll cover:

• BANT
• MVP
• RFP
• Questions

Fasten your seatbelt, we’re starting right away.

All you need to know about BANT

BANT deals with your budget, however, the budget itself is not the only factor IT companies consider during the valuation process. 

BANT is a method that software development agencies commonly use to verify that project assumptions and expectations fit within a particular budget and, to put it shortly if they make sense. Verifying the project at the outset may enable both parties to better understand the project, come up with alternatives, or simply avoid disappointment and misunderstandings in the collaboration. 

BANT stands for four terms: Budget, Authority, Need, and Timeline.

• Budget: one difficult aspect of sales requires asking the client about his finances. However, most believe that the first step is always an open dialogue with the client – examining their problems skillfully and rendering a solution for his needs.
  
  This stage answers questions such as:
  Are the budget and resources adequate for the scope of the project?
  Are the clients ready to pay and adjust the budget?
  
  
• Authority: this stage is important for both parties to verify whether the collaboration is doable. The software development agency wants to determine whether or not a potential client is fully prepared to move forward with a partnership and, if so, under what conditions. It is intended to verify the seriousness and real interest of both parties in order to respect their time.
  
  This stage answers questions such as:  
  Who is going to verify and approve tasks?
  Is the responsibility scope clear for everyone? 
  How to communicate changes? 
  Are we on a decision-make stage? 

• Need: this stage identifies the real need behind the request, features as well as functionalities of the software that is to be developed. This is also where the USPs are identified, a competitive analysis can be conducted, and use cases are to be determined.
  
  This stage answers questions such as:
  What is the problem that the product or service will solve?
  What makes it different from anything else available?
  What’s the goal?
  
  
• Timeline: the deadlines are aligned with the expectations. The number of versions and fixes is determined and matched with the budget and resources. It is important to go through this phase in order to determine whether or not the project will meet deadlines or face delays, as well as if it may incur additional costs.
  
  This stage answers questions such as:
  When is the final product scheduled to be launched?
  Can additional costs, in order to speed up the process, be justified?
  What’s the approval process?

Going through BANT is highly beneficial for clients, who can verify whether they are on the same page with a software development agency, acknowledge risks and challenges, and identify potential bottlenecks. In the end, this may reduce time both to them and to IT companies, who may choose to resign from taking the project if they are unable to deliver it within the proposed framework.

While BANT is a method that many software development experts implement, it’s not the only one you’ll encounter. Another alternative is the MVP, which, in short, is a smaller test version of the project in order to verify its business sense. 

Let’s briefly switch to this one.

The importance of MVP in software development

Is there a need for the MVP in all projects? No, probably not. However, if every project in the world went through it, then probably some of them wouldn’t have been developed the way we know, or they wouldn’t have failed.

MVP is one of the easiest methods for validating or specifying a product or software idea. 

The MVP is a limited version of a given product that offers the essential and most important features to verify if the final product will be successful. It describes the fundamental and basic functions that constitute the value of a product. In this way, the software development agency receives feedback on the functionality of an application, and the client can verify whether the selected path makes sense or not.

By creating an MVP, the main intent is to be able to get a quick and reliable evaluation of an idea or product during the testing phase. Here at CrustLab, we often recommend this solution to clients who work on “under construction” projects or whose ideas might benefit from extra validation. We could also suggest conducting workshops where the vision for the project could be developed together with us.  

However, this does not always have to be the case. You may already know precisely what you want to accomplish, don’t you? And those requirements and expectations are usually incorporated into the RFP. 

RFP: what to know about Request For Proposal

The term RFP is an acronym for the request for proposal. Frequently, it also includes RFQ (request for quotation), including the signing of the contract and setting the conditions. This step is more detailed – a client who has an RFP often already knows what he’s looking for, what he can afford, and what kind of cooperation he wants. Software development agencies can ask for additional information, and workshops are also an excellent way to clarify any doubts.

Even though an RFP is not mandatory at the onset of collaboration, it is beneficial, even if created in a short version, for both parties. This may allow a software development partner to better understand the project’s foundation and point out areas to revisit. RFPs also allow for the provision of alternative solutions and provide accurate estimations of the time and cost of the project. 

This gives the client predictability and provides flexibility to plan in time and budget and enables them to present a demo version to investors or potential users. RFP may also create an opportunity for quicker entry into the market and more profitable earnings.

There is nothing wrong with not having a request for proposals (RFP) – not every project or product had one at the outset. A reliable software development partner should be a real partner at this phase, too, and guide you through the whole process regardless of your RFP, or its lack. They should understand – and navigate through – what the customer’s business needs are, what functions will be fulfilled by software/product, the distinctive features of individual businesses, the business applications, what the product offers to the market, and what its main sales value is.

Here is a sample RFP for your reference.

RFP template

• Information on the document version.
  
  
• Introduction:
  • a general overview of the industry,
  • competitive analysis and/or examples to follow,
  • design benchmarks and preferences,
  • the goal of the project,
  • the roles and accesses required within the project,
    
    
• Definitions of industry terms that may appear in the RFP.
  
  
• List of basic functions for each role.
  
  
• A list of all views to be included in the application, along with sufficient design examples, preferably mockups, even though they are often not ready yet at this stage.
  
  
• Detailed descriptions of each subpage and its individual elements:
  • footer and header,
  • description of the offer in full,
  • photo gallery – layout & content,
  • content on subpages,
  • elements such as tabs, categories, shopping cart, favorites, booking calendar, etc.,
  • admin panel,
  • possible payment methods,
  • other features, such as price and promotion algorithms, offer search engines, filtering.
    
    
• A separate description for the mobile version.
  
  
• Technical requirements: technology, traffic KPIs, supported browsers or devices, test environment, required integrations; SEO requirements.
  
  
• Formal requirements – How to submit the offer, when it should be submitted, through which channels, who should be contacted if additional questions arise, and so on.

An RFP like this may be sent to several software development companies in order to obtain the best offer and pick one for the actual development. However, many questions will arise, not only from the client’s perspective. 

Questions a software development company may ask

In fact, the more information development companies ask about, the better it is for the entire project’s future. Asking questions does not indicate poor knowledge or lack of skills; rather, it indicates the software development company’s willingness to get to the bottom of the problem and provide precise estimates. 

Although there may be some predefined templates and patterns of questions (as you’ll see below), they are usually individual cases depending on how complex the RFP is. Some questions may already be addressed in the RFP or may simply need clarification as they only scratch the surface, but there may be numerous areas not covered at all. 

Should there not be an RFP at all, questions will accumulate quickly. 

The importance of being proactive at this stage and providing answers quickly may improve the overall process, speed it up, and enhance collaboration, which will all contribute to a successful final project. 

Below are some frequently asked questions (and their variants) by software development companies upon receiving an RFP or a simple request. Take this more as a guideline for what can be asked and what details may be required to provide. There could be hundreds and hundreds of questions in this stage

1. Stage of project development:
   – How long has the project been in development? (if applicable)
   – Is the project monolithic or is it organized into microservices?
   – Could you provide more information about the project architecture itself?
   – What types of tests were conducted?
   – Has a static code analysis been performed?
   – To what extent does domain knowledge contribute to the success of the project?
   – Has the monitoring of system operation been undertaken?
   – Did any large-scale custom systems have to be considered in the implementation of the modules?
   – What technology was used in the front end?
   – Which version of Java does your server run?
   – On what modules does the whole system currently operate?
   
   
2. Team & collaboration:
   – How many people will make up the development team and what is their hourly commitment during the week?
   – Which methodology is adopted by the team?
   – Under the current status quo, will the support be limited to maintaining the current version of the product, or will it be possible to develop new functions?
   – What was the development team rotation throughout the project?
   
   
3. App specifications:
   – What is the minimal version of the operating system the application should support?
   – What is the main UI framework?
   – Will the project be marketed through official platform stores?
   – What level of analytics will be required for the app?
   – Will the app need payment processing?
   
   
4. Additional features:
   – Should the offline mode be supported, developed, and synced?
   – Are third-party authentication services planned?
   – Does the biometric authentication need to be supported?
   – Will push notifications or in-app messaging be utilized in the strategy?
   – Is multi-language support provided for this product?

Of course, those are only a few questions that could be asked. Various factors may be involved, such as the project’s scope, budget, technology, and requirements. Although, our list may have shed some light on how specific – or generic – some questions are.  

Now it’s your turn 

If you stumbled upon this article, and now arrived at this point, then it is likely that you are interested in working with a software development agency. Well done! The better prepared you are, the more successful the collaboration will be. Mark our words.   

No matter if you have already established an RFP or never heard of it until now, if you have run an MVP or not, you should have a good software development partner on board. We know one – we are one. Get in touch, and we will be glad to guide you through your journey.