Avoiding Hidden Costs in Software Development

“What's it going to cost?”

We love hearing this question. Not because we have some bizarre affinity for the budgeting process, but because we see discussing cost with potential clients as an opportunity to get clarity on project strategy. This will ultimately help you maximize the ROI of your product—and it allows us to demonstrate our value from day one, before we write a single line of code.

Some firms may rush or oversimplify the bidding process, which can turn into a major liability for you in the long term. We're not the experts in your business—you are—but often, we find that we need to recalibrate the expectations of our clients and educate them on the hidden costs of development decisions.

We want your software to have the greatest impact it can—and to do that, we'll help you budget your project to avoid unnecessary costs and delays caused by technical debt.

Technical debt is the invisible, costly drag on a project resulting from:

1. Solving the wrong problems (e.g., over-designing and over-engineering)
2. Solving the right problems in the wrong way (e.g., prematurely, or based on incorrect assumptions, accelerated deadlines, or bad coding practices)

Technical debt doesn't just lie hidden as cumbersome architecture in your software codebase that needs to be fixed or worked around. It also affects your bottom line by way of project delays, buggy software, expensive rebuilds, and, ultimately, user satisfaction.

While technical debt can be difficult to see, it can be avoided. First, ask yourself detailed questions about your project—and make sure you're being asked those questions by the developer as well (see our examples below).

In addition, if you have existing code, you should consider paying for a code audit. Any reputable digital agency should be able to do this for you.

Here are some of the questions we often ask our clients before bidding a project:

1. What are the goals and necessary features of a minimum viable product (MVP) version of the software? (This functions as a hypothesis of your value proposition—ideally, you'd get a chance to refine it based on real data.)
2. What meaningful data can be gathered from the MVP version, and how can it be used to refactor development goals?
3. What are the probable goals, features, and design decisions of an ideally finished product?
4. Do you want a web application, a mobile application, or both? If a web application, does the software need to respond to different screen sizes? If a mobile application, should it be compatible with iOS, Android, or both?
5. Do you have existing brand materials, style guidelines, or design libraries, or do these assets need to be created from scratch?
6. Will the design of the application be simple and straightforward, or will it have embellishments such as custom icons, illustrations, and/or animations?
7. How will a user be onboarded to the application? How sophisticated of a user onboarding system is required?
8. What number of active users are you expecting in the short term and long term?
9. Are there any security or compliance requirements (e.g., HIPAA, HL7, PCI)?
10. Do you have examples of other applications on which you'd like to model decisions?

If you're not being asked these questions by a prospective software development vendor, there's almost no chance that their answer to the question, “What's it going to cost?” will have any real utility or reflect the quality of work needed for a high ROI on your project.

Please don't be fooled by a low price tag. Simpler and cheaper decisions now are likely to end up costing you more later—and by later, we mean pretty soon.

In conclusion, while cost is a necessary metric by which to compare vendors, we also encourage you to take into account which vendors are capable of giving you the highest ROI on your investment.

We take pride in our work and our ability to set you up for long-term success, and we practice what we preach by helping our clients gain clarity around project strategy and planning even before they've hired us.