The Myth Of Buying Over Building Apps

When I was a teenager, I got my first job at a small computer store. It was typical work, selling products, processing returns, handling service tickets, everything you'd expect from a consumer-facing job.

The computer store had a policy of checking any returned product's serial number to ensure it matched the receipt. The problem was that the "point of sale" (QuickSell) software purchased by the company had no direct way to do this. You had to click through every sales order and invoice until you found the matching transaction.

Needless to say it was tedious, time consuming, and sometimes downright frustrating for both the sales person and the customer. The QuickSell vendor had just recently been acquired by Microsoft, and there was essentially no hope of support or getting them to make improvements, especially since we were just one tiny inconsequential customer to them.

Using my amateur programming skills, I set out to rid the computer store of the problem and created a software tool to scan the point of sale database for a given serial number, and show the transaction details on the screen. It didn't take long before it was ready and available on all the store computers.

Returns suddenly went from taking a ludicrous amount of time, to almost none. Customers were happy; Sales people were happy; The software worked; And I walked home with $40 in my pocket from the owner.

Almost a decade later, I walked into that store to say hello, and they were still using that little tool. How much time had it saved that company? In all those years, how many customers went home satisfied that the company could quickly process their return or exchange?

The efficiency of that business process was essentially quadrupled, or more, and all for a one-time investment into building a piece of software tailored to that computer store's needs.

The Myth

I recently read an advertisement that was stating that businesses should avoid custom built apps and instead pay for "customizable" apps as a service. Their reason: technical debt and cost. They didn't give much evidence for the argument, but it did get me thinking about the reality of build vs buy when it comes to the intricacies of business software.

Technical debt occurs when a complex system implements a simplified solution instead of the best solution. As time passes, it generally becomes clear that the best solution should have been implemented in the first place, and additional cost is needed to facilitate the bridge between the simplified solution and the best solution.

There's no doubt in my mind that poor-quality apps, whether purchased or built, lead to technical debt, but what about when both are high-quality? Does a high-quality bought app really have lower technical debt that a high-quality built app? Are built apps really more expensive?

Get ready for the bombshell...

but before that...

Story Time

Let me tell you about Tom & Maggy the IT managers in different companies. Both Tom & Maggy are ready to implement a new software tool to handle their incoming shipments. They have narrowed their options down to two high-quality vendors. One, Appreciable Media can build the app the organization deems best, and another, SomeSoft, has an app available for use with millions of customers already.

For both Tom & Maggy, Appreciable Media says the app will cost about $200k to build, while SomeSoft says it only costs $150/user/month to use their app and is available immediately. SomeSoft says they include extra features in their tool as well: video chat and an integrated blog system.

Tom is quickly attracted to the SomeSoft solution, it sounds so affordable! Of course, a lot of people will want access, but he can control those costs. Also think of all the cool features, everyone will be blogging and video chatting in no time! Tom chooses to buy the SomeSoft app.

Maggy is wary that the SomeSoft solution may not fit with the all the specialized requirements of the users, and could end up costing quite a bit if too many users need access. So Maggy chooses Appreciable Media to build the custom app for them.

Fast forward 3 years. Tom's SomeSoft solution has cost the company nearly a million dollars and many worker needs are being unmet, which is hurting Tom's customer base.

Maggy on the other hand is happily looking for more ways to improve efficiency in new projects, as the Appreciable Media app continues to hum along.

So what happened?

Time makes fools of us all. Tom fell victim to the trap of not quantifying efficiency potential.

By choosing to buy a commercially available "generalized" app as a service, Tom ended up hurting his organization's efficiency potential, that is, the money saving power of good automation. Specifically:

  1. Tom was forced to limit the number of users to the app to keep costs down. Fewer users were able to take advantage of the efficiency power of the app (automation). Maggy had no such limitation, the app was built to her organization's specifications and she could add as many users as she wanted.
  2. Tom was dazzled with flashy tech features that had no actual value to the purpose of the business process. Users ended up wasting time learning and using the video chat and blogging features until they ultimately went unused. Maggy, on the other hand, got exactly the features needed to keep users focused on the important business processes.
  3. Niche features and requirements of Tom's workers and customers were omitted, overlooked, or incorrectly presumed to be of low-importance, just so the cost savings could be justified. Tom actively decided against proper project planning because he improperly presumed the generalized app could handle almost anything, when in fact, it was limited in it's flexibility. Many of the goals to increase efficiency fell by the wayside or were only partially met. Maggy had all the bases covered, and since the app was planned and built specifically for her organization, there was clear and concise coverage of requirements.
  4. Tom ended up having to pay for a variety of add-ons and had to force users to use impractical workarounds because the SomeSoft support team refused to support a feature that only Tom's organization needed, they were just one of the product's customers out of millions. Maggy never had to purchase an add-on, or open a new account with another third party vendor. Appreciable Media added the features, as requested, to the original app and aligned priorities with her organization.
  5. When Tom wanted organization-specific customization, he ended up paying a premium for specially skilled teams of consultants that had the very specific know-how of working with the SomeSoft software. Maggy, although happy with her current vendor, could choose to hire internally or externally almost any R&D vendor she'd like, because her app was built on universal standards and well-established software design practices and languages.
  6. Every year, Tom is forced to pay the amount demanded by SomeSoft. Every year or so, SomeSoft increases their price and Tom is essentially forced to pay. Maggy's organization, however, owns the custom built app in-full. She doesn't need to worry about renewing costs or unexpected price changes, just small expenses to add feature or apply maintenance. So what does this mean? It means Tom chose a simplified solution, but it wasn't the best solution.

What Is The Efficency Potential Of Business Software?

Efficiency potential of business software is the power to save money through good automation. This savings is almost always, in some way, quantifiable by evaluating how much time it saves workers and frees them to do other important work.

For Example...

Jeff is an accountant at a medium-sized pottery company. Every day he has to check his e-mail inbox for Excel files from the retailers, and move numbers from them into a larger Excel file for analysis. As the company grew, more and more files came in every morning and it took more Jeff's time. Jeff hated the tedious work. So Jeff decided to determine the efficiency potential of an app to automate the work, and pitch the idea to the company executives.

He found the company could potentially save more than $100,000/year.

He figured the efficiency potential using the following factors:

  1. Jeff would save 3 extra hours a day, or $19,500/year savings at his pay rate of $25/hr. $25×3×5×52 (pay × time savings × working days × weeks in a year) = $19,500/year.
  2. Jeff will be free to tackle other more important accounting work, and he could see that additional orders would be processed each day. The support staff would spend less time dealing with angry customers, and the refunds that may have resulted. The resulting app could end up saving the company $78,000/year at the 20-person support staff salary rate of $15/hr. 20×$15×1×5×52 (staff × pay × time savings × working days × weeks in a year) = $78,000/year.
  3. The spreadsheet for analysis was ready almost instantly, executives were able to make more timely decisions, and were able to react to market changes. This was hard to quantify, but was worth mentioning to the executives.

Even though the app only affected one process, the efficiency potential was enormous, as it's automation affected a long chain of business processes.

The Bombshell

The stories in this article are, of course, fictitious, but many are based on my experience working with over 25 different companies of all sizes. In them, I'm also presuming both the bought & built app are high-quality, crafted by vendors that hold to rigorous standards and business practices. One thing, however, that must be realized, is that they are different types of vendors.

A vendor focused on selling an app as a service needs to provide an app that "generally" fits their target market. A vendor focused on building an app for a customer is focused on providing an app for that customer.

The bought app is simplified for the audience. It has to appeal to the broadest customer base as possible, and it's easy to forget that most business processes are complex, and that complexity is sometimes not a bad thingYou can't cram a star shape into a square hole, and even if the hole was big enough, wouldn't it miss the point?

Technical debt occurs when a complex system implements a simplified solution instead of the best solution.

It turns out that the advertisement I found was indeed spurious at best. An app you buy instead of build isn't a solution to technical debt. The app you buy is the technical debt.

A common misconception is that that time to market is technical debt, which it is not. A custom build is going to take longer to become available to users, but it is also an excellent opportunity to refine and produce a well thought-out solution.

Ultimately each organization needs to decide whether a bought or built app can truly align with the business goals and requirements, and meet the efficiency potential goals. I'm not advocating that businesses look to build their own version of Microsoft Word.

Nothing I've said here is set in stone. There are easily many factors that could affect a new technology project. My point is to really think ahead. Think about your priorities, and your vendors, and whether or not they align.

I urge technical decision makers out there to really choose wisely when considering their organization's technology. It's a decision that can end up lasting decades, just like that little app for the computer store. In my experience, when it comes to unique, custom business processes, you'll likely be better off building than buying.

From The Author: Christopher Eaton

I hope you enjoyed this article and that it helps bring perspective to your decisions. If your organization needs help building that custom app or updating your business technology, don't hesitate to reach out to my start-up Append Media. You can also contact me directly through LinkedIn. Thanks for reading!

Christopher Eaton