7 Reasons Why You Should Treat Your Custom Application Like an Employee

When I was in high school I knew I wanted to work in technology, and there was a time when it seemed like joining the military would be a good way to get on-the-job training. I was only in 11th grade at the time, so I signed up for early enlistment which meant I started going to reserve duty every other weekend but wouldn’t get any formal training until after I graduated. The problem with this scenario is that technical jobs require training, and since I still had a year and a half to go before I could get any training, my reserve duty consisted mostly of sitting in a room and occasionally doing some PT. They still paid me for this time, even though I wasn’t at all useful to them. Such is government work. 1

Typically when an employer has a role to fill they hire someone who can do that job or can quickly be trained to do so. Most companies, government organizations excluded, don’t hire someone without first having a well-defined role for them, but many companies approach custom software development that way. So when a potential client comes to us looking to have a custom application built, one of the first things we want to know is, what’s its job? Whether it’s going to be a mobile app, a website, an API, an embedded system, a device driver, or whatever, every custom application ultimately works for that client, just like their employees.

Bonus e-book: Soup to Nuts: Taking an Application Idea to Reality

It’s easy to look at software as a tool. I have many tools on my computer – a calculator, a couple of text editors, a graphics editor, several testing and debugging utilities, etc. When I need a calculator, I open the calculator app; when I don’t need it, it sits on my hard drive doing nothing. Some of these tools cost money for licenses, and when those tools sit unused there’s a cost associated with that. Of course almost all the licensed software I use was built for a general audience and sold to hundreds if not thousands of customers, so if my $99 office suite sits unused for a while, the cost is not a huge loss to me; the license fee is still worth the few times I do need it. Custom software is a much different story. You can’t often have a custom application built for $99. More often it’ll be $1,000’s, $10,000’s, or maybe even $100,000’s worth of development, and chances are you’re not going to want it to just go unused a majority of the time. Given that, let’s look at a custom application not as a tool, but as an employee.

Let’s assume you are an employer and you are looking to have custom software built:

  • Your employees typically have a specific role – sale associate, accountant, secretary, customer representative, etc. So to will your custom software. It will solve a particular workflow problem or inefficiency, so its job will be to facilitate the process that is a pain point or bottleneck without it – tracking data, responding to events, up selling products, organizing information, and so on.
  • Your employees typically have performance goals that are evaluated annually – efficiency, training schedules, attitude, sales targets, and the like. Your custom application will too – throughput, effectiveness, usability, scalability, etc., and they should be routinely evaluated by conducting user surveys, comparing metrics, and tracking resource usage.
  • When your employees’ performance is not up to par, you may require that they undertake training. Likewise, if you find that your custom application is not performing up to par once it’s in production, it may require retooling or optimization of the underperforming parts of it, such as by addressing usability issues, optimizing slow database queries, or adding a caching layer.
  • If instead an employee outperforms expectations, you may decide they deserve a bonus, promotion, or raise. If you find that your custom software is outperforming expectations, you should reinvest in it! Perhaps adding new functionality, or increase redundancy in the event of an emergency, expanding it to new departments or rolling out a campaign to promote its use to your customers or audience.
  • Your employees may have a salary associated with their employment. While it’s not an exact equivalent, your custom application can be considered to have a salary as well – first the upfront cost of development, and later the annual cost of maintenance for security fixes, bug patches, and upgrades.
  • Your employees also have other costs associated with them, such as taxes, health insurance, licensing, and equipment. Similarly, your custom software will have other expenses that must be factored in, such as hosting fees, hardware and peripherals, 3rd party licenses, storage, and monitoring.

With all this in mind, wouldn’t you say your custom software looks less and less like a tool and more and more like a new employee?

I have one final comparison, and perhaps the most important. To maximize the benefits of hiring a new employee, you must be sure that employee will be able to stay busy, otherwise you’ll be throwing money away. With custom software, if you’re not constantly using it, promoting it, driving traffic to it, and keeping it updated, you will also be throwing money away. You will need to make sure you keep your software working for you by making sure it’s being used for the purpose it was designed for. Ensure that employees are trained on it and use it consistently, or that customers can access it and find useful content. If it’s publicly available, like a website, ensure that you’re constantly adding content so that Google and other search engines keep indexing it. Don’t fall into the “if you build it, they will come” trap. Put it to work, and make sure it stays busy.

Custom software can be an expensive investment, but if you design it to do a job and invest in it like an employee, you’ll be able to track results better and budget for it accordingly.

Bonus e-book: Soup to Nuts: Taking an Application Idea to Reality