Shopping for custom software development for your business can seem like a daunting task. A lot of SMBs aren't even aware that there are companies out there that provide custom software services, let alone know where to begin to look for one. And even if you do know where to look, how do you know you're going to get something that's worth what you're paying, or even what you should be paying in the first place?!
First, there are a large number of custom software development companies out there. A quick Google search for "custom software developer" yielded me over 5 million results. That's not a bad starting point. You can also try reaching out to other businesses or even your local chamber of commerce for recommendations. Or, if you're really ambitious, check out a local tech meet-up to see if you can find someone that can handle your project.
Once you've found a few options, it's important to discuss other software projects the company has completed and to get references from the companies they've worked with to develop custom software. If possible, try to get your hands on the software they've built. This step might be a little more difficult as custom software (or at least a subset of features) is often proprietary to the organization that commissioned it.
The cost of custom software development can vary greatly depending on your needs. In general, expect to pay an hourly rate of anywhere from $125 - $250 depending on who you're working with, what their experience level is, and the market(s) they serve. If your project is reasonably significant in scope, you should count on at least a couple of engineers, possibly a designer, and a project manager that will be involved in your project.
Remember that custom software is going to be significantly more expensive than the subscription or up-front fees you're used to paying for other software. Commercial software allows you to split the cost among hundreds, thousands, or even tens-of-thousands of other users; custom software means you're footing the entire bill. On the other hand, commercial software limits you to the feature-set someone else has decided to provide to you, where custom software gives you the flexibility to design something entirely for your organization.
Also remember that once the software is built, it needs to be maintained. No software is ever bug-free, and the nature of technology means that as the environment changes (operating system updates, new security requirements or exploits, new devices that need to be supported, etc.), your software will need to change with it. Your investment in your software is only beginning with your up-front development costs.
It's often difficult for many people to understand the costs of software development because it's not a tangible product and the purchaser or end-user rarely takes a peak under the hood to see what was actually produced by the software engineer(s). The most common response I get when I discuss custom software development costs with SMBs is generally one of shock and disappointment that the idea they had isn't even close to being in the budget. But it's important that you realize what it takes to build a quality piece of software.
Software engineering is the single-most in-demand career we have in this country right now. It's simple economics; suppy and demand. Quality engineers come at a cost. Additionally, good software takes time to build. It's easy to build a piece of software that performs a certain task in an isolated environment. On the other hand, building networked applications that need to sync across devices and users in real-time while accounting for varying conditions and different environments takes time and requires a significant amount of testing to ensure a quality release.
The environments we use to build software are also not cheap to purchase, install, and maintain. Bandwidth costs money. CPU time costs money. Electricity costs money. The software and hardware we use to build and test software costs money. It also takes time to build out quality test environments, to maintain servers, and to keep up with the pace at which our field changes on a day-to-day basis. All of these costs need to be accounted for somewhere.
Which brings up another issue: Should you outsource your custom software project overseas where these costs are lower or should you keep it in-country or hyper-local with someone you can sit down with and visit when you need to?
My recommendation on the outsourcing question is to leave outsourcing to someone that has the technical know-how to know exactly what they can outsource and what they shouldn't.
Outsourcing a software project to another country brings a tremendous amount of challenges that shouldn't be attempted by someone that can't read and evaluate the code that's being produced. Cultural differences are tricky enough, but even just the time difference of working with someone halfway around the world makes this a tricky prospect, especially for someone with no experience managing a software project.
I can't think of a single exception of a piece of custom software I've seen commissioned by a SMB overseas that didn't result in a failed implemenation or, more commonly, a total throw-away and rebuild.
Ultimately, it's important to view a custom software investment the same way you would look at an investment in new equipment. Just because it's not a tangible item you can hold in your hands doesn't mean that it shouldn't be evaluated in the same manner.
These investments come with a cost, they come with quality and service differences based on the vendor you choose, and they're only worth making if they offer a commensurate return on your investment. Similarly, the more substantial the investment, the higher your margins need to be or the greater volume you need to be doing to justify the risk.
Thinking about paying $100,000 for a piece of software is difficult for a lot of SMBs to wrap their head around. However, if that software allows you to eliminate the need for an employee while increasing sales and providing a higher level of service to your customers (for example), it's pretty easy to justify.
This article originally appeared on Chris Searles Blog
Last updated on