The Pitfalls of Hiring a Software Development Company (From the Former Owner of One)

Has your company outgrown off-the-shelf apps and spreadsheets? Custom software built specifically for your company’s many unique needs may seem like the perfect answer. However, what if there was now a better option? Read on to discover the pitfalls of hiring a custom software development company today, from the former owner of one.

Selecting the best fit

Whenever you're looking to build a piece of custom software, you'll want to make sure you get multiple quotes from a number of different companies. You'll likely be surprised how varied the responses will be both in terms of time and cost. Figuring out if the bidding company really understands what you're looking for vs. trying to low-ball, or milk you for as much as possible, or worse...both.

You see, sometimes a software development company will provide a low bid because they know you're going to want more development in the future, or they quote out the bare minimum functionality set to get the job done, but not to do what is really needed. Conversely, the larger bids will likely encompass a full solution based on your articulated needs, but at the end of the day, they're still going to need to manage changes and just like the beginning bid, those changes will be equally expensive.

When I owned my software development company, I always made sure we were working in the best interest of my customers, but if we had never worked together prior to this engagement, how would they really know or believe that? That's what every company would say, so check for references from repeat customers as they will hopefully be able to vouch for at least their experience.

Managing change controls

Changes will ALWAYS come up, no matter how well you planned or thought you relayed the requirements or needs. It's the nature of the beast when you're building your own systems. The world is your oyster and new ideas will materialize during the development process that you just have to have. This isn't necessarily a bad thing, but eventually you're going to need to make decisions on the additional costs; it will either cost more, or you'll pine for that feature in the future. And when features are slid in, sometimes at low cost, corners are cut when the design or architecture doesn't quite fit the new feature requested or built.

Locked in for changes

For those changes that didn't meet the budget or timeline constraints that you wanted to get in, you're going to need to have someone build those changes. You can go with the original company – assuming you had a good experience, they'll be happy to keep billing you for building on your systems and adding features and complexity.

You could also opt to take it in-house, or to another vendor as well, just be ready for the new developers to scratch their heads at the code they inherited, and 9 times out of 10, they'll recommend they rewrite all or parts of it. They won't understand how the code was written, why it was written that way (changed feature perhaps?), or they won't like the language, or have no documentation from the prior developers, or a plethora of other reasons. The scariest of reasons is that it’s actually some really bad code written poorly, insecurely, or stitched together with chicken wire and duct tape.

Strong as their weakest link

Who is really doing the coding? Unless you're working with an extremely small shop (solo developer or two), you likely won't know who exactly is writing the code and what their qualifications and credentials are. If it's a larger project, you'll likely have a team or two working on the codebase.

Unfortunately, unless there are multiple (and expensive) controls in place for code reviews, you're going to find that the code may only be as good as the worst programmer who was working on it. Most good software development companies will have some controls in place around this, but as projects go on, and those scope changes come up, and those feature requests pile on, is there some corner cutting happening as well? Where were the corners cut?

The art of maintenance

So if you're happy (or at least happy enough) with the project and software that was delivered and you're not planning on adding features for the time being, you'll want to at least make sure the system is maintained. What can happen with software once the software development company is done with it is it can very quickly become outdated. It was built for the here and now, and perhaps not with the foresight on what would happen when the database grows, or data gets stale, maybe domain names change for web applications, or branding, or a plethora of other changes.

Will you be able to handle those changes yourself? Maybe your internal IT department can take it over...but at what cost? As previously mentioned, maintenance will almost always need to be considered when taking on a custom software project.

There’s a better way

Nothing helps a company achieve efficiency more than a custom solution that is tailored specifically for their business and their process. Unfortunately, for all but the small few companies that are either in the business of building software themselves, or who can employ teams of software developers, the benefits of custom software are seldomly realized to their full extent. This isn't because the software development company they hired were bad, per se, but because of the nature of business and software in general.

Business changes and the custom software that was or is being developed for your company is trying to hit the moving target of the changing business. The more nimble the development company, the more ability they'll have to change the software for the business. Unfortunately, that comes with a high cost. That's why OptimumHQ came into being: enabling a company to change their software without hiring internal or external developers to build or maintain the system. All the benefits of a custom solution for your business, at 10% of the time and cost, and none of the pitfalls.