Custom software development pricing strategies

1. Custom software development pricing strategies

How to evaluate proposals from IT contractors?

How to Evaluate Proposals from Potential Contractors.

Mad Devs Customer University is a series of publications aimed to help customers choose the right contractor and maximize benefits from working with them. We will address every aspect of customer-contractor interactions to show how to achieve a truly profitable partnership. 


Here, we give an overview of what to look at in the proposals provided by different vendors.

Finding the right implementer for your tasks may take a long time and can be frustrating, especially if you have deadlines creeping towards you. This is why it is important to make the searching and hiring processes as efficient as possible.  

Before you even receive a proposal from a potential contractor, you normally spend time:

  • Finding companies or individuals who may be interested in and capable of doing the job you need,
  • Corresponding and negotiating with them, and 
  • Researching their backgrounds and previous work through portfolios and client reviews. 

At this stage, it may be wise to shortlist the contractors from whom you even want to receive a proposal, and here’s what to take into account:

  • Communication patterns: the way potential contractors communicate with you during the pre-proposal period is a quite accurate, if not prettified, reflection of how they work generally. If they’ve already missed a couple of deadlines or made promises but never delivered, you may not want to bother waiting for a proposal from them. 
  • Portfolio: if you checked their materials or examples of their work and didn’t like those, perhaps the contractor is just not right for you. 
  • Compatibility: take a look at who the company or the person worked for before to see whether your business is similar to those. Naturally, if you are an aspiring startup, and the guys you want to hire have been working for large companies lately, there is simply no match.

The quoted price gap

Custom software development offer

Picture it: I’m a customer; I’ve received a few proposals from teams who I think can do the job right, but the proposals are totally different. The teams are going to approach my project in completely dissimilar ways. The gap between the lowest and the highest quoted price is vast. I’m frustrated and don’t even know where to start to evaluate the proposals. 

First things first: let’s consider the price extremes. If the quote is unexpectedly low or unexpectedly high, it will normally mean that the contractors didn’t put too much effort into the process of estimation. Anyway, here are possible reasons:

Unexpectedly low price

  • The contractor is planning to launch your product in its minimally viable form as soon as possible but does not presume you will need further support, maintenance, or improvements. (Signs of this are the lack of descriptive documentation, lack of automated tests, and poor architecture.)
  • The contractor is ready to sacrifice certain parts of the development process that are not essential but necessary if you want perfect results: an example is extensive testing on several stages.
  • The contractor has analyzed the scope of work negligently and gives you an unrealistic quote; the quoted price can later go up.
  • Rare: the contractor is a fraud; they want to get at least some money from you and are not planning to deliver any product at all. (A sign of it is the lack of documentation explaining what exactly will be done and how.)

Unexpectedly high price

  • The contractor is a big company; they’re not too much interested in small-scale clients, and their estimation for one can be somewhat frivolous.
  • The contractor is overcautious and plans to involve many specialists in the development process to safeguard the high quality of the final product. What the contractor is afraid of here is a lack of certainty in your technical requirements. 
  • Rare: the contractor wants to rip you off. (A sign of it is the lack of documentation explaining what exactly will be done and how.)

Factors that shape software pricing

The way a potential contractor will approach your project will depend on not only your specifications but also the contractor’s expertise, corporate structure, availability of specialists, and many other factors. Now let’s take a look at what in a proposal can help you understand whether you want to work with this contractor or not. 

1. Pricing model

Some guarantee they’ll do the job for a fixed compensation, and some suggest starting off on an hourly basis. What to choose depends on how well your tasks are specified. If a fixed price is proposed, make sure the contractor has a convincing description of how they’ll handle the tasks: they must be sure they know what they’re doing if they’re going fixed.

  • Fixed price: includes the cost of potential risks (it can be 20% or 300%, you never know), and detailed requirements are a must, but there is no flexibility or scope management, and there is, sadly, no guarantee you will get the result you’re picturing in your head now.
  • Time & Material: there is no guarantee you will get the project implemented within the budget, but there is more flexibility in the development, and approaches can be agile. This option is also usually preferable in long-term projects because it implies a more or less stable monthly budget and allows adjusting requirements without having to receive approvals on each small task from the contractor’s entire management.

2. Scope of work

Do the contractors describe in detail what they’re planning to do? A good estimate will surely show that the contractor has figured out what the customer means and what he or she needs. Consider the following:

  • What are the components of the estimation? Are they general or detailed?
  • General components: e.g., the estimation features three sections—backend, frontend, and design—and says that the development of each will take, say, three weeks. Such general estimates provide to the customer little to no understanding of how exactly the components will be developed, and this may prevent you from making an informed decision.
  • Detailed components: the estimation elaborates on what technologies will be used to implement specific functions, includes the work of project managers, QA specialists, and other professionals, and predicts possible complications and risks. A meticulous approach most likely reveals the professionalism and knowledgeability of the team.
  • What questions had the team asked before preparing the estimate? Were they relevant and insightful? Did they pay attention, ask follow-up questions, and apparently try to gain insight? If you have three yeses, you’re on the right track.
  • Are the questions the contractor asks you strictly technical? Some choose to stay safely within your specifications, while more experienced contractors will critically assess your ideas and suggest doing things in a way that, say, will be more competitive on the current market. So their questions will include those about your target audiences and business goals. 

3. Team composition 

  • Seniority level: it’s important to whom the contractor is planning to entrust your project. To tackle some tasks, you need senior specialists, while other tasks can easily be handled by juniors. You should not worry about having low-level professionals on your team, but you should make sure the contractor explains in which parts of the planned work they think juniors will do just fine and why.
  • Selection and communication: you need to know that the seniority level of the team members can be verified. Can you interview them before accepting their terms? Can you communicate with the team directly? If not, you may want to look for mediators who can help you make sure that the level of your contractors is as declared.

4. Tech stack

Obviously, the same tasks can be completed through the use of different technologies, and the tech choices are major contributors to the final estimate. The key considerations here are: 

  • Development vs. integration: how much custom software do your contractors propose to develop? If ready-made modules or libraries will be used, do the contractors justify this decision?
  • Backend: what languages and frameworks are proposed? The choices between, say, Python and JS or between Swift and Objective-C will depend not only on what the contractors are capable of handling but also on what they think, based on their expertise and research, is viable and popular in the industry now. 
  • (In mobile development) Native vs. Hybrid: do your contractors propose to develop applications separately for different platforms or to use cross-platform technologies? Depending on project objectives, there are advantages to each of the options.
  • Specialists: the costs of work vary from technology to technology, and some contractors may simply not have the right specialists available for your project at the moment. Make sure, though, that the allocation of tasks is done according to your purposes and in your best interest as opposed to the contractor’s convenience only.

5. Use of ready-made components

As mentioned above, some may offer to develop things from scratch, and others may suggest integrating third-party services. 

  • Development from scratch: maybe more reliable but is expensive. 
  • Integration: may be faster, but the final product will depend on a lot of external things. Also, this approach may not actually be so cost-efficient because existing solutions can be rather pricey. 
  • Example: admin panels. You can buy ready-made admin panels from many online services, and they can work just fine for you. However, experts suggest that each such solution has its limitations, and if you hit those in the implementation of the project or later, you’re in trouble. An admin panel developed from scratch provides more flexibility, but it is costly and time-consuming. There’s no universal answer: the decision needs to be made between the customer and the contractor in each individual case.

6. Organizational and development processes 

Pay attention to the complements to the estimate, if any. A contractor who knows what they’re doing will attach documentation describing the organizational and development processes, product architecture if needed, and the tests that will be administered so that the risk of failures is reduced. The things we recommend to look for in the proposal are:

  • Transparency: the contractor is totally open about what will be done and how; the processes are not described vaguely or obscurely.
  • Knowledge Management: the contractor explains how the knowledge and experience of different team members will contribute to the implementation of the project.
  • Communication: the contractor expresses themselves clearly, and the documentation is overall readable and appealing.

Conclusion

The considerations in evaluating a proposal are evidently diverse, but that’s just the tip of the iceberg. What has been attempted here is to show that proposal evaluation is a complicated process; the potential contractor and the materials they provide need to be assessed in various contexts, including your business’s size and specific characteristics + your willingness to take the risk. In virtually any real-life scenarios, things will pop up that haven’t been mentioned here.