Should you build custom software? It depends on which kind of problem you have.

Building custom software is like sculpting with clay—you can create just about anything you can imagine. Whatever your unique business process is, custom software can be coded to handle it in a streamlined and elegant way. It enables you to differentiate your product offerings and create repeatable value for a large number of users.

Sounds amazing, right? Here’s the catch. Custom software isn’t cheap. Custom software projects commonly range in cost from tens of thousands of dollars for basic applications to millions of dollars for advanced platforms.

It’s a huge sticker shock, but when you think critically about the cost, it makes sense. Designing and implementing amazing solutions requires many smart people and time. The reward for the investment is an asset that can be replicated and leveraged by many users to save time or generate new value.

On the other hand, the proliferation of SaaS (software as a service) products makes it more likely than ever that you can leverage someone else’s custom software investment to solve your own problems (e.g. become a user of someone else’s software instead of making your own).

That raises the question: Should you look for someone else’s solution to your problem, or should you build custom software?

To best answer that question, you should give some thought to the type of problem that you’re facing. In my sales role at Atomic, I commonly see three types of problems. Each problem benefits from a software solution, but only one warrants a custom software investment.

1. Software for Common Business Problems

Generic software problems are experienced by many people across multiple business verticals. These types of problems are commonly hiding within more complex situations that appear to warrant custom software.

For example, say you’re an insurance agency and you want an app to better communicate with your field agents (questions, photos, etc.). You use email for communication today, but that’s a pain because no one ever knows where to send the emails, and working with your email client on your phone is tedious—especially if you need to send a bunch of photos.

On the surface, a custom app sounds like a great idea. The field agents will enjoy the experience, home base will have better control of message flow, more information will likely be collected, and it will be easier to sort through message history. Hopefully, this will also lead to a better and more differentiated experience for the end client.

If you take a step back, stop thinking about the implementation of your problem (e.g. a mobile app that does X,Y, and Z), and instead consider the broader context, you will come to the conclusion that you have a generic collaboration problem. Your problem that felt very unique is in fact something that many people face. Collaboration problems are common.

When you come to this conclusion, the next question to ask is not, “How can I solve this problem?” but instead, “How have others solved this problem?” The first place to consult is Google. Half the battle of consulting Google is knowing the right question to ask.

For software solutions to generic problems, try the following search query: best X software. In this case, replace X with “collaboration.”

This phrase tells Google that you want results for the best-in-class collaboration software platforms. It’s highly likely that one of these solutions will meet the majority of your requirements. It may not work exactly like you want, but:

  • It’ll be much better than what you’re doing today.
  • The cost will be minuscule compared to building custom software.
  • You’ll be able to use it immediately.
  • There will likely be a large network of specialized contractors who can help if you need it.
  • You won’t be responsible for updating the system as the world changes.

For generic problems, I always recommend that you start with an existing solution. Starting with generic software doesn’t prevent you from going custom in the future.

2. Software for Not-Quite-Unique Problems

Not-quite-unique software problems are problems with needs that are specific to your business, but generic within your business vertical. They require you to consider the broader business context within which you operate.

For example, say you’re a restaurant and you want to provide a rewards app for your patrons. The goals would be to establish and reward loyalty, drive visits during slower times, and improve the patron experience by making it easier to make reservations, see deals, pay bills, etc.

The entire experience feels very custom. You’ll certainly want the app to be branded to your restaurant, and feel differentiated from your competition.

Once again, if you zoom out, you’ll realize that such an app isn’t really a differentiator for your business. The features that you’re looking to provide are the same that any restaurant would want to provide to their patrons. You could certainly hire a quality firm and design and develop an amazing app, but you likely don’t have the budget to invest in a project that could easily cost $100,000+.

Luckily, you don’t have to. Since software can be easily replicated and shared, it’s common for software companies to serve a specific vertical and provide white-labeled solutions to that vertical. A white-labeled solution is really just a generic solution that’s branded and customized to a specific client. These types of companies are able to leverage the IP that they’ve established within a certain vertical and provide a more affordable solution to many clients (e.g. amortize the cost of platform development across many customers).

These solutions will cost more money than generic software solutions. However, compared to custom software, they will still be a fraction of the cost, delivered more quickly, and probably updated with some sort of yearly support fee.

For not-quite custom problems, try the following search query: white label X app. In this case, replace X with “restaurant.”

The term “white label” is important because you want to brand the app. With this example, it’s also important to use “app” instead of “software” because you’re looking for a mobile experience. Using “software” instead will likely provide options for a white-labeled point of sale system, another not-quite-custom problem.

Just like the generic problem case, starting with a white-labeled “not-quite-custom” software solution doesn’t prevent you from going custom in the future.

3. Software for Unique Problems

Custom software-worthy problems are specific to your unique business process, or a component of a solution that you’re selling to your clients (new value).

Please note: Just because you have a unique problem doesn’t mean you should build custom software. Remember, custom software development is expensive. Many times, unique problems have limited scale and should be solved with people instead. When evaluating whether you should solve your problem with custom software, ask yourself this question: What’s the impact of not doing the project?

I like this question because it gives you another way to think about the pain you are addressing, or the opportunity of value creation that’s in front of you. If the pain is low or the opportunity isn’t that significant, it’s likely that the cost of a custom solution will always be prohibitive.

My personal rule of thumb is that the value a custom software solution creates either through cost savings or revenue generation should be at least 3-5x the cost, or the consequence of not doing the project should be significantly impactful to your existing business (e.g. if we don’t invest, our current offering will lose value).

Custom software is a powerful and magical tool. When leveraged correctly, it can generate immense value, but when it’s foolishly used, it can be a financial mess.

Atomic is happy to help you identify the type of software problem that you’re looking to solve. If your problem is custom, we’re an outstanding partner to lean on. If you problem isn’t custom, we’ll honestly share our thoughts and send you in the right direction.