In the world of software consulting, it can be virtually impossible to determine what the fair market value for software development is. Nobody estimates work according to the same parameters: some firms have differing rates for differing services, some have offshore development services, some won’t provide a meaningful estimate at all (and for good reason).
So, as a business owner or CTO, you evaluate any number of proposals. One probably says something along the lines of “we have no idea how long this software project will take, but we’ll bill you a consistent amount of money per month until you decide you are done working with us.” Another says something like, “this project should take between 6 to 12 months to complete”. Another probably says “this project should be in the ballpark of $200,000” which, in practical terms, means somewhere between $200,000 and $400,000.
Evaluating the real costs of a software development proposal
When it comes to cost, all three proposals are basically pretty similar. Nobody really offers fixed-price projects, even if they say they do, and any software consultant who is being realistic knows to create enough space in their proposal to leave themselves somewhere between 50 and 100% wiggle room on a budget. The most honest proposal is probably the first, but again, in practical terms, they probably all add up to about the same amount of money laid out.
So you look at the different firms’ capabilities. They’ve all executed big projects successfully in the past and have solid technology chops in your desired tech stack. The first one is maybe a small firm in an up-and-coming tech hub, probably <10 employees, but all passionate and good at their jobs. The second one is maybe a large firm based in a large city with an onshore headquarters, but with offshore development services that allow them to beat the other two firms on hourly rate by a significant margin, but the trade off is communication and understanding. Say the third firm is a mid-sized small business, established, with a wide breadth of expertise and onshore development, but a slightly higher rate than the first company, and a significantly higher rate than the firm with offshore dev.
None of the firms stand out more than the other in terms of their technical ability to accomplish the project. Where one firm might appear better than another, there are balancing points that level the field. You might spend less per hour on the company with offshore dev, but you’re probably going to put more hours into communicating with them, particularly if the project manager is offshore as well.
So what do you do? You’ve got to make an effective business decision here, one that balances budget, schedule, and execution and, in the final rinse, all the companies more or less look alike. As the guy who is usually on the other side of the table trying to convince you I’m the best man for the job, my advice is to focus on the consultant who best understands the set of problems you are trying to solve. If one of the companies seems to understand that set of problems better than the other two, it doesn’t matter how much more expensive their rate is, and it might not even matter that they offshore their development. In the long run, they are likely going to be your cheapest option, even if their quote is the highest (assuming process and methodology are otherwise more or less equal between the three firms).
Hiring a consulting firm to review your software development
But value can be hard to measure, especially in a large project. Let’s say you’re 12 months into an 18-month development schedule, and the board wants to evaluate the work that’s been done. They hire a consulting company to come in and review the work you’ve done with your current developer. This slows everything down, takes a month, and probably costs you about $15 or $20K. They come back with good news and bad news. The architecture is solid, the code is well written, but they think you should have been further along in the process for the time and money you’ve poured into the project. It’s a rare thing that they are going to tell you that everything looks great and you should continue on with your current developer. Many software consultants treat a code review as an opportunity to get a new client. It’s a sales effort. It may produce real, actionable issues, but that isn’t really it’s primary goal, or, if it is, that goal coexists at an equal level of importance and urgency as the secondary goal, which is to convince you that they are the better firm to complete the work.
Fair enough. Maybe they uncovered some important flaws that you need to address. But do they understand the problems you are trying to solve better than the company you chose originally? Out of the three firms you had to choose from when you were collecting proposals, you decided that your current developer had the best grip on your problem set, and they’ve had 12 months to tighten that grip with your help. Do you think that that software consulting firm that has spent all of a month reviewing their code now has an even better understanding of that problem set? That seems dubious to me. So unless this new consulting firm can demonstrably show you where your current developer has been grossly negligent, and at the same time show a remarkable and unique understanding of your problem set, I have to think you are better off continuing on with your current developer. Maybe there was some tension between you over the mistakes they made, but as long as the mistakes aren’t show-stoppers, they probably have a better chance of getting you safely to your delivery point than anyone else.
There are legitimate reasons to check up on your development team. If you’ve had bad communication experiences with them, or have legitimate reasons to worry about the quality of the work they are doing, or, if you are working with an offshore firm and are exploring the option of taking your business onshore, those are good reasons to hire a third party firm to check into your project. But if all you’ve got to go on is a vague feeling that you might have gotten off with a more cost-effective option, you are probably better off sticking with the horse you rode in on.
