The Pros and Cons of Building Custom Software

Splash image denoting pros and cons of custom software

The decision to buy an off-the-shelf solution or build a custom solution is one that every business must make. It’s a difficult choice, as there are many pros and cons of building custom software. To help you make the best decision for your business, we’ll a look at both software acquisition approaches.

Purchasing Off-The-Shelf Software

When it comes to purchasing software, there are several advantages to consider. First and foremost, buying commercial off-the-shelf (COTS) software is upfront cost savings – both in terms of time and money. When you purchase a pre-built software solution, it’s often much faster (and cheaper) than attempting to build something from scratch.

Additionally, a large user base means that the COTS has likely been tested by thousands of people. This limits the possibility of bugs or glitches before you incorporate the software into your workflow. This means less risk on your part, and fewer headaches down the road due to compatibility issues or other problems with an untested system.

Of course, there are also downsides: namely, lack of customization options and potential vendor lock-in issues. These could be especially problematic if they decide to stop supporting their product, or get acquired by another company. Additionally, since pre-made solutions need to cater for a wide range of customers they may not always provide intuitive user interfaces or enable personalization options. This can leave users confused, or force business to change their processes to match the software.

Lastly, if the “out-of-the box” solution doesn’t quite meet all your needs, it tends to be difficult – or impossible – for it do so without significant customization. Theses customizations can be expensive and unstable, negating the cost savings from buying pre-made solutions.

Building Custom Software

One major advantage associated with building custom software is having total control over the product. Businesses can ensure that the system meets all their needs, without the limitations of “off the shelf” products. This allows for greater internal adoption and implementation as it lets the software conform to the business, rather than the business conforming to the software.

Additionally, custom software allows for greater flexibility and scalability. Since the code for these applications is proprietary, companies may find themselves with a competitive advantage against those using shelf systems. Custom software allows companies to respond to user feedback quickly by developing better tailored versions to improve user experience.

Lastly, as businesses grow the shortcomings of a one-size-fits-all approach are magnified. Inefficient processes amount to hundreds of lost hours throughout the year. All while recurring expenses rise due to increased users or added features. Since businesses are stuck “renting” technology, they are unable to reap the benefits of owning their technology. In many cases, medium-size businesses are able to see positive ROI in as little as three years by developing their own custom software solutions.

Conclusion

The needs of every business are different. Understanding the pros and cons of each software solution alongside the specific profile of your business is critical to making the right decision. At Sigao, we invite you to do the research with us. We’re happy to help you assess the software needs for your company. 

To find out more, schedule a discovery meeting today!

Do I need custom software?

Man confused by plans for a custom software system

As veterans of the custom software industry, our team has encountered countless questions about the creation of custom software solutions. However, few questions are as difficult to answer as the very first one.

“Do I need custom software?”

Software is wildly complex, both from an engineering perspective, as well as a business value perspective. Today’s applications can touch so many aspects of an organization that accurately gauging the investment can be a challenge. On top of that, no two engineering firms are the same. Some may provide ultra-specialized engineering services for one aspect of the project, while others may provide broader, more consultative services that cover more of the project scope.

The natural reaction to attempting to process too many choices is to intuit the answer. To try to “feel” that the variables are pointing one direction or another. This is dangerous as it leads to Confirmation Bias, giving you the impression that all the information you discover appears to point in the direction you want it to point.

In this article, we’ll discuss some tangible aspects to consider that will provide a framework for making the decision. Keep in mind, this is too complex of a subject to cover in one article. Our hope is that this information provides valuable measures that help you feel more confident about the process.

Analyze the “Why” Behind Your Custom Software

Every software project begins with the same thing: a problem.

Unfortunately, people are good at solving problems.

Take a minute to think through the last problem you solved. It can be anything. Maybe your phone wasn’t working, or your car was making a weird noise. Whatever it was, think about how you instinctually responded when you discovered the issue. I’m willing to bet that the first thing you did was immediately start trying to figure out the underlying cause.

Did you mull it over in your head, vetoing unlikely scenarios and coming up with new explanations. Maybe you googled the issues, trying to find others who have solved this problem. Whatever path you took, its very likely that you got sucked into finding a solution without paying much attention to the problem its self.

People are hardwired to solve problems. We’re good at it, and by and large, we enjoy it. Unfortunately, that aptitude leads us to dive into solutions, while giving the problem only a cursory glance. Maybe the cost to fix the problem isn’t worth it? Maybe the problem opens up doors to fix other areas? What if there’s an ugly, but effective solution that’s far easier than the obvious solutions?

For small, every day problems, the downside of ignoring this kind of deep analysis is minor. A few hours here, a few dollars there, no big deal. Yet, software projects are huge investments, with vast consequences. Most problems are solvable, but the real question is should you solve them?

Know your problem, ignore the solution

Nothing related to a solution matters at this point. Not the price of the solution, not the technology (or lack there of) of the solution, only the problem. Our team consistently encounters people who “know” what software frameworks we need to use to solve the problem. Yet these people often are not able to describe the problem in detail. They’ve allowed themselves to dive into the solution without truly knowing the value of the problem, which makes the decision little more than a gamble. Before moving forward, these are some of questions you should be exploring:

  • How many people does this problem effect?
  • How much time/money do you lose from these effects?
  • Are there 2nd or 3rd parties affected by the primary party’s issues? How much time/money do you lose there as well?
  • Are there multiple facets to this problem? If so, which is the most valuable to solve?
  • Are there adjacent issues that you can address in tandem with the primary issues?

The more you can understand the problem, the more you can assist other’s to build a good solution.

Why knowing your problem is so critical

The less you know about the value of the problem, the more you end up guessing about the value of the solution.

At its core, a software project is a continuous cost/benefit problem. You expend X amount of effort for Y amount of return. If done correctly, Y ends up significantly larger than X. Because of this, one of the largest factors in a successful project is how well those involved understand the problem.

The less you know about the value of the problem, the more you end up guessing about the value of the solution. Each decision becomes a gamble, rather than a calculated risk. And you will be making decisions if you continue down this path. As the owner of a project you will face a constant stream of decisions related to the value of your solutions.

Do you sign off on using a 3rd party tool that costs $100/month, but will end up saving 2 months of project work? What if that feature is only solving a problem that costs a handful employees 10 minutes per day? Engineering groups can provide information, and some (Sigao being one of them) can even assist in analyzing those choices. But, the final decision must come from those who understand the problem the best.

The next reason is perhaps the most important. It’s what elevates project outcomes to to their maximum potential:

Extreme understanding of the value of the problem allows for the most creative solutions.

Knowing your problem fosters innovation

Knowing what is and isn’t important allows the engineering team to propose creative solutions. My favorite example of this is what happens in some of our initial discovery meetings. People will often approach us to build a project having already landed on a desired solution. They’ve spent weeks or months imagining a complex solution that addresses ALL their problems, without knowing the value of those problems individually.

This is a common scenario, which we address with an array of discovery questions. We try our best to help our customers refined down the most valuable aspects of their solution. During that process we occasionally encounter situations where the value is so concentrated on one aspect of the problem, it allows us to bypass the majority of their requirements. If only a handful of requirements are worth the investment, why bother with the others?

The results are often eye opening. Given a narrowed scope, the team is free to adopt a more Rapid Testing mindset. We’re able to suggest ideas that may not even involve writing code, but will solve the problem quickly. This allows the customer to assess portions of the solution individually before committing to a large scale system. Sure, these solutions are typically “quick and dirty”, but the amount of value they provide negates the downsides.

Its not uncommon for our customers begin a meeting envisioning a $50k+ system , only to leave the meeting with a way to solve most of their problems for free. All because they were able to recognize the most valuable problems to solve.

That’s the power of understanding your problem. When you know what’s most valuable, you gain the ability to make more intelligent decisions about where you invest your time and money.

Long Term “Why” Behind Your Custom System

One of the biggest issues we struggle with in the software industry is conveying the benefits of a custom solution. It’s difficult for people to get past the initial shock of the price, and a lot of that is because they haven’t truly considered the problem their solving.

Custom software systems are like sports cars. Expensive to build, expensive to maintain, but capable of doing amazing things. Part of knowing your problem is knowing how much the value of the solution builds up over time. If you a development team quotes you $300k for the solution, is that bad? Maybe. What if it will save you $70k per year and will turn a profit in 3 years? What if you’re currently paying $40k/year in subscription costs which will disappear after the project?

Think back to the “adjacent issues” you explored. Could owning your own data provide more opportunities for value over time? Could you later pivot your solution into a product that you then sell to other companies similar to your own?

Time is a powerful factor when considering the problems you’re solving. Solutions typically provide value for long after the initial project cost.

How Much to Invest in Custom Software

By now, lets assume you have your problem mapped out. You know how many people it affects, how much they lose, and how much money you’re losing by not addressing the issue. The next question is, can you feasibly afford the solution?

Custom software is expensive, and there’s not much you can do about it. Even if you are absolutely convinced of the value of your project, there will still be significant investment to get to the end goal. There’s no cutting corners if you expect good project outcomes, which is why its so important to know what you stand to gain. We plan to cover this topic in more detail in later articles, but for now we’ve provided a reference table for you to plan against.

Keep in mind, many factors affect these prices. Some seemingly difficult features are solvable in days, while others that appear simple can take weeks or month to accomplish.

Reference Table For Estimating Project Costs

Project Type
Price Range
Description
Simple Marketing Website (Contractor)
$1-5k
A simple marketing website meant to display information, built by an independent contractor. Primarily needs to look good, function on mobile. Functionality would be limited to simple contact forms.
Simple Marketing Website (marketing firm)
$5-30k
A simple marketing website meant to display information, built by an experienced marketing firm. Primarily needs to look good, function on mobile. Functionality would be limited to simple contact forms. Typically would include more robust designs/mockups, more help with hosting, as well as maintenance and trouble shooting.
Proof of Concept Web/Mobile App
$30-70k
Web or mobile app, built by an engineering firm, designed to show that the intended functionality is possible. May not be complete, or visually appealing. May not scalable. These are typically used to attract investors.
Mid size Web App
$70-300k
Web or mobile app, built by an engineering firm, designed to accomplish a business function. These may absorb several business areas, allowing the company to remove multiple paid products from their workflow. This price range may also be applicable beta product launches, depending on the complexity of the product.
Enterprise Web App
$300-1,000k
These are large, overarching systems that touch multiple aspects of a business and hundreds of users. These systems have multiple integrations with other systems, multiple roles throughout the organization, and strict uptime requirements. For new products, this range would likely cover several major versions of an early stage product. If promoted properly, a new product with this much investment should typically be generating revenue and attracting large investment firms.

Follow Through with your Custom Software Project

You know your problem, and you have an idea of what its going to cost. Now what?

If you have the corporate backing or funding to move forward, the next step is to start evaluating vendors. Spend time finding a group that’s trustworthy and has a proven track record. Make sure their clients willing to vouch for their capabilities. Find out if they hide the development team, or let you interactwith the people building your solution. Finally, make sure their contracts are set up to share risk on both sides of the project, rather than pinning it all on you.

Most of all, find someone you get along with. There WILL be stress, there WILL be miscommunication. The best way to navigate that is by working with someone you trust.

Final Thoughts

Assessing whether you need custom software is a difficult task, but it doesn’t have to be guesswork. Sure, you won’t always find perfect ways to assign value to the problems you’re trying to solve. You won’t always have all the information you need to make a perfect decision. However, with a little effort, even the most complex problems can be evaluated and broken down in a way that empowers you to make better decisions.

Have fun solving big problems!

Rapid Testing Mindset: A Powerful Strategy

Perfect Doesn’t Mean Effective

Rapid testing is not something that comes naturally to me. As an engineer and a creator, I often find myself driven by the pursuit of perfection. In my spare time I spend days and weeks on woodworking or home improvement projects as I hone my skills and improve the quality of my work. In fact, I’d guess that just about everyone has a skill or interest they want to learn and work hard to improve upon. Likewise, I’d guess that most people view the pursuit of greater skill and higher quality output as the path to success. For the most part I would agree with them.

It may then surprise you that one of the most powerful strategies in business is to NOT pursue perfection.

Examples of this strategy are evident everywhere in the business world. New services often launch with messy, unintuitive signup processes. B2B applications rarely end up with clean, visually appealing interfaces. More and more products are releasing in “generations” rather than perfectly finished designs. In fact, while writing this article I prepared ramen with instructions to “ignore the indicated fill line” rather than the manufacturer simply providing a bowl with a correct fill line.

These trends are all coming from large companies with resources and talent capable of making their work “perfect”, so why are so few of them pursuing it?

80% of Consequences Come From 20% of Causes

To understand why, we first need to understand the Pareto Principle, also known as the 80/20. First proposed by management consultant Joseph M. Juran, the 80/20 Rule states: for many outcomes, roughly 80% of consequences come from 20% of the causes. While originally used in the context of quality control, the principle has been successfully observed in many practices. In fundraising, 80% of the funds raised typically come from 20% of the donors. In computing, developers can typically fix 80% of software issues by addressing the top 20% of bugs.

What people often overlook is how this holds true for business activities as well. You will likely capture the majority of an activity’s value at the beginning, with returns on investment diminishing as the effort continues. Although the perfect solution may in fact be achievable – and even more valuable – this principle shows us that the point when expended effort becomes a net loss is far earlier than “perfection”. Within that final 20% of quality lies the vast majority of our time and energy, which would be better served accomplishing 80% of several other business outcomes.
In short, perfection wastes time and money.

Speed is the Optimal Path to Success

The chart below represents an 80/20 curve relating to the business value of tasks. Each bar represents a task and its measured business value. What the 80/20 Rule shows us here is how 80% effort is “optimal” in relation to the value we get out of our actions.
Diagram showing the diminishing returns that rapid testing lets you avoid.
However, with concepts as abstract as “effort”, shooting for a real number is futile. We can’t accurately quantify our effort, and even if we could, landing directly on 80% would be virtually impossible. How do you put in exactly 80% effort when doing things like deciding on sub-contractors or creating sales collateral?
If more value exists at the beginning of our efforts than at the end, it stands to reason that taking too long is more costly than finishing too early. Thus, our goal should be to focus on speed.
By focusing on speed, we ensure that if we miss the 80% mark we still “fail” in the most efficient manner. To see this in action, imagine two identical startups selling their own widgets. As these businesses grow, both startups realize they need some sort of CRM to manage customers and orders. Startup A, recognizing that this is a core part of their business, launches a two-week research project to determine the absolute best fit for their company. Startup B, however, spends an afternoon researching options then picks one that seems decent.
Fast forward two weeks… Startup B realized they rushed their decision and some business processes will have to remain manual. However, they now have two weeks of customer data in the system and are using this data to create sales strategies. Startup A ended up with the “perfect” solution with all tasks perfectly automated, but no data to determine sales strategy. They are now two weeks behind their competitor. Only now are they starting to enter customer data, and it will be another two weeks before they have enough information to start developing a sales strategy.
Startup B captured the bulk of the business value (a way to build a sales strategy) despite rushing the research task and failing to address some lower value business processes with their purchased software, whereas Startup A missed out on leveraging high value results because it was stuck waiting on “perfection”.

The Difference Between Rapid Testing and Recklessness is How Much You Learn

At this point you may think I’m encouraging you to act recklessly. I know I certainly thought that the first time I saw these rapid testing concepts in action. There is a final aspect separating recklessness from strategic speed: learning. Or, more accurately: you should frame your pursuit of the 80% value in the context of learning new information to apply to your next decision or action. When you treat every next move as a deliberate test for gathering information, you gain the insight to deploy your effort where it matters the most.
Let’s go back to our startups. This time Startup B had massive problems with the software that they selected. A purely speed based strategy would tell them to pick the next best software and cross their fingers it would work better. Technically they would still accomplish more because of their speed, but they also would still be charging down the same path without knowing if it was the right path. What happens if they treat the decision as a test with the explicit purpose of learning about their sales needs?
By framing it as a learning-based strategy, Startup B would pay closer attention to the business value provided by the software and note what conditions would cause them to change directions. These insights could lead to a better next pick but, more importantly, this deliberate focus on learning may reveal that the company’s business process doesn’t actually need a CRM at all.
Maybe these widgets require a unique sales process, or maybe a CRM is too complex and unwieldy to use efficiently at this stage. If that’s the case, their next action would be to pivot quickly to some other solution, completely abandoning the goal of getting a new CRM and saving money in the process. By inspecting the results, Startup B will gain business value even in failure.
Speed helps you get to your goal. Testing helps you determine if your goal is correct.

Rapid Testing Mindset is a Powerful Strategy for Innovation

Regardless of job title, everyone is operating with an incomplete understanding of their environment. Whether we know it or not, we conduct experiments every day with every action we take. Despite this – maybe even in spite of this – many companies punish failure and expect every result to be positive, leading employees to push deeper into the low value, time-wasting activities as they attempt to be “absolutely sure” their results will be positive.  Some byproducts of this risk aversion are lower creativity and lower trust between employees.

However, companies that embrace rapid testing, and the failures that come with it, create an environment suitable for innovation. When the organization’s goal becomes learning, failures no longer carry negative weight. Instead, failures are celebrated as steppingstones towards better results. This environment is critical for innovation because, by definition, innovation is the exploration of the unknown. Exploration cannot exist without risk and creativity. If perfection is expected and failure is not an option, the business will get mired by group think.

Even failure-embracing organizations can stifle innovation if they remain focused on perfection. Innovation is a time-consuming process, often taking hundreds of iterations to find the best solution. When perfection is expected before results are known, these types of organizations will spend the majority of their time on the low value items that make up the last 20% of quality.
If the 80/20 Rule holds true, every “perfectly” completed task sacrifices the same effort as five 80% completed tasks. That’s four missed learning opportunities for every attempt. The result is large feed feedback loops, low agility, and even abandoned projects as the effort to gather new information becomes too costly.
Organizations embracing rapid testing will experience failure. It will be messy and often chaotic. However, these organizations will also generate business insights far more quickly than their competitors. They’ll be more agile, more responsive to changes, and, by necessity, foster cultures of exploration and creativity.