One of the challenges facing companies and organizations that need custom software development is how to control costs and at the same time maximize their chances of a successful product build. When sourcing development partners, founders and leadership have difficult choices to make, and it isn’t always easy to know what the right path is, especially when they get widely varying budget estimates.

Companies should be mindful of the budget of course, but sometimes what seems like an attractive low-cost solution can become a nightmare, and it is a scenario that happens far too frequently.

The cost for software development is actually very simple:

Hours Spent  x  Hourly or Day Rate  =  Total Cost

Of course, the complexity comes in how many hours it takes to do the project, and hourly rates can vary widely. But every software estimate is essentially that formula.

The most difficult question to answer, when talking about budgets, is how is it possible that one software developer can estimate one price, and another might be double or even triple that? It’s something that comes up frequently, and in this post, we’ll dig into why there can be such widely variable budget estimates, and how companies can make better decisions.

 

The Fixed Price Game

While most software is developed using agile methodologies these days, there are still some developers who will offer a fixed price (waterfall development). In this scenario, the company needs some software developed, and they might even have a scope document that outlines what they want. Developer A looks at the scope and says they can do it for a fixed cost of $35,000. Developer B says they can do it, but they are an agile development shop, and they estimate that a reasonable budget is $75,000 to $100,000. The price differential is tempting, but what’s really going on?

When a developer underbids a software project, there are several potential reasons for that:

Image
The developer is gambling that they can actually do the project within the hours estimated, and it will all work out just fine.
The developer is desperate for work and is willing to do the project cheaply to keep the lights on and it might lead to other work, so they take the project.
The developer believes they can limit the scope to a bare bones build, and then upcharge you for things that are not in scope.

None of these scenarios work out well for anyone. Something’s got to give, and it’s either quality or functionality, or both.

The client might think, “Well, if the developer underbid it, that’s their problem. They will need to deliver.” In reality, that’s a lose-lose proposition. If the developer lost the bet that they could actually deliver the software at that price, they begin to cut corners to mitigate the damages. Any requests that the client makes is a change order, and a costly one! It breeds mistrust, creates adversaries instead of partners, and gives a poor-quality result.

 

I Know a Guy…

Hiring an independent developer introduces a special set of risks. Their cost estimates are often wildly optimistic, which results in cost overruns and missed deadlines.

While some independent developers are competent of course, in our experience the quality of development that comes from the one-man-band developer is often poor to say the least.

Independent developers with no one looking over their shoulders often lack the discipline to fully document their code and have bad practices with lots of short cuts that results in stability, scalability, and performance issues. If anything can lead to having to scrap an entire codebase, this is probably the most common reason.

Sometimes the independent developer doesn’t have the full skill set and experience with projects of that scale. It isn’t easy to develop an entire digital product from ideation, prototyping, design, UX/UI, front-end and back-end development, database architecture, testing and quality control. Each of those skill sets are not easily embodied in one individual, but all are required for a high-quality product.

 

Offshore vs. Onshore

While offshore development is not automatically a bad thing, it introduces enormous risks, especially for non-technical leadership. The apparent hourly rate can be extremely attractive, which is hard to resist. Sometimes it works, but often it doesn’t.

We see a much higher percentage of partial or complete product failure with offshore developers than with onshore teams. Why is that? There isn’t any one single reason, but here are just a few that we see frequently:

Image
You don’t know who is working on your project. Some of these factory software farms churn out software using inexperienced developers that produce low-quality code. You won’t know until you run into stability issues, or try to scale, and the costs mount as they try to triage your platform.
Offshore teams are often not collaborators, they are order takers. Even if they are competent, someone must task them in detail on the project scope. For a company with little experience with software development projects, it’s easy for things to go off the rails.
Communications and logistics can be a nightmare. Language and cultural differences, not to mention huge time zone offsets can make managing the project challenging, to say the least.
They use the wrong tech stack. While there is no single tech stack (the technologies and programming languages used to build the software) that is a good fit for all projects, we have seen offshore developers use fringe, outdated or even obsolete technical stacks that are not easily updated. When you need to switch development teams such as bringing software development back onshore, you can run into major blockers.

 

Critical Functionality is Left Out

This is one that comes up a great deal. The client says they need an app that does certain things, and the developer leaves out critical needs that they know they will be an upsell opportunity later.

For example, we had a client come to us recently that had gotten a quote for an app that was extremely low. The project was for a digital product that was fairly straightforward on the front-end, but the back-end and logistics pieces hadn’t been fully scoped yet. The client had outlined the basic app functionality, and the developer estimated it based on that outline.

But it was clear that the developer hadn’t included estimates for functionality that would have been needed like dashboards, data integration, reporting tools, customer onboarding, subscription management, payment gateways, and many other things that are required to have a fully functional product that was ready to take to the market. Instead, they would have gotten a barebones, standalone app with minimal functionality and nowhere near ready to go to market.

 

Lost Opportunity Cost

The lost opportunity is, in many ways, often the highest cost of a failed product launch. We have seen delays of months and even years with a development process that drags on, with no end in sight. That time is never recoverable. Those long delays can result in not being first to market, or never even getting there at all.

 

Final Thoughts

When developing digital products, the complexity of the process requires a team of talented developers with a wide range of skills, and who will be good stewards of the product and the budget. Choosing a team based largely on the cost introduces enormous risks by marginalizing essential skillsets required for a successful product.

Take the time to really think through who you want to partner with. Your decision should not only be based on technical competence, but also culture and values. If you do that, your chance of having a successful project increase dramatically.

WE LOVE THE PROBLEM

Schedule Your Free Strategic Project Review & Project Brief

Developing great digital products is our passion. Not sure how to start that journey? Let us help you find the right path. Schedule a free 1-hour consultation with our team. At the end we’ll deliver a Project Brief that will help you to crystalize your vision.

 

Schedule a Consultation

Image