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.


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!

How does a Feature Workshop help define your Software Solution?

How we refine your software solutions’ needs, wants and expectations into a usable roadmap in just one day.

Our Feature Workshop is an interactive collaborative brainstorming session facilitated by a certified scrum master. In our world, it is the cornerstone exercise for refining the needs, wants, and expectations of our client’s vision into a usable road map.

The goal of the Feature Workshop is to form clarity from chaos, direction from misunderstanding, and identify the minimal time to business value.

4 Phases of the Feature Workshop:


The first step of our process is homework (sorry!). This is where we gather the high level information about the solution, such as:

  • Product Name
  • Goals
  • Target Users
  • And other factors that determine if the product is a success or failure

All of these questions will help us better understand the problem you are trying to solve and help us determine the right kind of questions to ask during the workshop.


Brainstorming is the meat of the Feature Workshop day. The goal of this section is to challenge participants preconceived ideas about the solution, while recording any and all new ideas that are generated. Its our job to collaborate with our clients and ask the questions that make them say “Huh, I hadn’t thought of that”. While the point of this section may not be to perfectly define the scope of work to come, we believe that somewhere, buried in the piles of resulting sticky notes, are the gems that will solve our client’s problem

Now, Next, Later

One of the foundations of Agile development is the concept of smallest possible feedback loops.

Gone are the days where projects are expected to stay shuttered and hidden, only being released upon 100% “completion”. Instead, the Agile community has embraced the fact that business problems change much faster than solutions can be completed.

What good is the ultimate business solution if three other competitors have launched, failed to interest customers, and pivoted to something new before it even gets in front of a user? Worse yet, not only does this place you behind the competition but now you’ve burned a large portion of your capital to get there, ouch.

This section of the process focuses on identifying the most important and least understood aspects of the solution and prioritizing them within a backlog of work items. Maybe your solution relies on unproven technology, or maybe the whole concept rides on the assumption that customers will use the solution in a specific way. We can make educated guesses about how these things will play out, but without validation it’s essentially a gamble, and one that companies lose every day.

By front-loading these types of problems, we’re able to minimize the amount of time (and money) that will take before a solution can start generating valuable feedback.

As the prioritization of work items begins to filter the riskiest assumptions to the front of the solution, another scrum concept begins to take shape. The Cone of Uncertainty is a term used to describe the decreasing variance in estimates as ideas are validated. It is almost a universal truth that early estimates are either naively low, or frustratingly high, and it’s this large gap that represents the base of the “cone”.

However, as stewards of our client’s vision, it’s our job to take this massive variation and narrow it as quickly as possible via early and frequent iteration over the aspects of the solution that cause this uncertainty. In doing so we’re able to drastically reduce the variation in estimates, provide more accurate projections, and reduce the chances of wasting resources.

Like most aspects of an Agile Methodology, the backlog produced in this section is intended to be reactive to an evolving understanding of the problem. As information is gathered, work that was previously considered critical may shift in priority or even be abandoned altogether. A well-maintained backlog will ensure that uncertainty is minimized and resources are used appropriately.

Relative Estimation

At this point in the process it’s time for homework on our end. We compile the results of your brainstorming, backlog creation, and prioritization, then gather our best and brightest minds to create our initial forecast of the solution in its entirety. Additionally, we’ll provide a separate, refined roadmap defining what we view as the minimum amount of functionality that can survive on its own, or Minimal Viable Product.

To do this, Sigao uses a proprietary relative estimation technique to produce our initial forecast of the solution. By assigning effort to new work items based on problems we’ve solved in the past, then estimating items in relation to each other, we’re able to create what we believe to be a realistic forecast for how long and how much it will take to provide a solution to your problem. While this often results in an estimate that is more uncertain than people are familiar with, we believe wholeheartedly that it’s better to be honest rather than make promises that can’t be kept.

We’re also proud to say that the vast majority of our solutions are completed near the center of our projections.


One of the most common misconceptions about an Agile process is the perceived lack of planning. For many, it seems inconceivable to begin work without piles of planning documents, generated by teams of business analysts, defining every feature and every milestone of the work to come. On the surface this seems like a logical conclusion. When time, money, and jobs are on the line, it’s a natural human response to seek comfort in knowing that there is a plan. People tend to focus on their successful predictions to trick themselves into thinking they’re capable of knowing the future, while conveniently forgetting about the number of times they were wrong.

Sigao’s response to this is simple: Name a single time you drove from one city to another where you were able to predict every turn you would make, every pothole you’d dodge, every traffic jam you’d encounter, and every animal that would run out in front of you along the way, before you even left your home. Now consider that a project will have multiple “drivers”, of multiple skill levels, all trying to do something infinitely more complex than drive a car. How comforted does an all-encompassing plan make you feel now? Ya, that’s kind of what we thought.

The answer is to visualize the solution at a higher level, acknowledge the uncertainty, and plan for it. Rather than trying to predict every fine detail, we use the prioritized work items to construct a forecasted timeline of high level feature completion (both for MVP and total solution backlog), with estimates becoming increasingly less accurate for work items farther in the future. The most valuable research will get done first because we’ve already front loaded the riskiest assumptions, which in turn will drop the uncertainty of future estimates.

This process is the reason that we reject the notion that an Agile Methodology does not involve planning. Our plans are just dynamic, and evolving, maintaining their relevance by being subjected to constant evaluation. We are always planning, from the Feature Workshop to the very last sprint. When we deliver the initial road map at the end of the workshop we’re providing an honest assessment of the information as it stands, with the expectation that it will adjust along with our clients’ needs and goals.

That was a lot of information! 

Let’s recap:

The Feature Workshop is a low risk, low effort way to define your solution. You’ll interact with industry experts that will advise on implementation. After, you will have a Forecast for your solution, identifying the minimal time to business value.

How Do You Practice Refactoring Code?

Refactoring legacy code can be daunting. While trial by fire is a great way to learn most kinds of programming, it doesn’t leave a lot of room for getting better at it (at least not quickly). 

When trying to hit a deadline it is often difficult to take a step back, try different techniques, and learn a few keyboard strokes to automate some of the more mundane tasks. Coding katas are one way we can hone our craft outside the pressure of deadlines and our day jobs. It’s even better if your day job encourages spending a little time now and then to improve.

What is a coding kata?

The term “coding kata” comes from one of my favorite programming books: The Pragmatic Programmer. “Kata” is a word borrowed from martial arts that describes a movement, or series of movements, repeated to perfect some technique. Applied to programming, it is an exercise that is repeated to perfect some skill.

Typically, these exercises are small enough to be executed in a short amount of time and can be solved easily. Once a problem and its solution are known, the programmer can then focus on technique:

  • learning keyboard shortcuts to increase speed
  • applying design patterns to make code easier to change
  • using test-driven development to reduce regression rates and produce cleaner code
  • etc.

Finding a coding kata to try is just a google search away. Another place you might start is here:

What is special about the Gilded Rose kata?

Most coding katas give you the description of a problem and maybe some other goals to make it more interesting. You choose the tools you like and start practicing.

The Gilded Rose, however, starts by giving you some code. It isn’t a clean code. In fact, if you think that it is good code I would genuinely like to hear your thoughts on what I’m missing. The poor quality of the code is part of the challenge.

Your mission, if you choose to accept it, is to clean the code up such that it is easier to understand. Having done that, put your new design to the test by adding a new feature to the code. If it is easy to add the new code, congratulations, you have succeeded. It need not stop at success, though. The next step might be to minimize the time it takes you to complete the exercise. Finding tweaks, like keyboard shortcuts or better design patterns, could build a technique that helps you to execute more effectively and efficiently in your day job when the stakes are higher.

There are countless ways to work this kata. It is my go-to when I’m trying to learn a new language, or refresh myself on a language I haven’t used in a while. I also use it in my coaching gigs because it lets me easily demonstrate a number of concepts in just a few hours:

  • Automated testing
    • Pinning tests
    • Test-driven development
    • Code coverage
  • Design patterns
    • Factory method pattern
    • Null Object pattern
    • Strategy pattern
    • Template Method pattern
  • Design principles
    • Single Responsibility Principle
    • Open Closed Principle
  • Refactoring techniques
    • Extract method
    • Extract class
    • Extract interface
  • Pair Programming
  • … and more

By the way, this kata is also a great way to try out a lot of different agile development techniques. 

How do I get started?

All you need to get started is the Gilded Rose source code in a language of your choice, the kata description/requirements, and your favorite development tools.

Emily Bache has a Git repository that contains the code for Gilded Rose in many different languages: It also has a requirements document describing the existing behaviors and desired new functionality.  

Factory Method vs. the Open-Closed Principle

I was recently asked if the factory method design pattern was a violation of the open-closed principle.

When you are adding a new subtype, you have to modify the factory method to enable to return additional subtypes. Also, you might be creating a new subtype for the factory method to return. Isn’t it an indication that you are violating the open-closed principles if you have to change multiple to files to enable a single new behavior? 

The open-closed principle states that entities (modules, classes, functions, etc.) should be open to extension and closed to modification. The factory method design pattern is a creational pattern that allows us to instantiate the proper type without specifying the exact implementation of that type. 

Consider the following:

  • The behavior of the factory method remains the same when you add the ability to return a new subtype; none of the callers of the factory method are forced to change
  • A new subtype that is created to be returned by the factory method is an addition by extending or implementing a type (hence, subtype), not a modification

If no behaviors have been changed, and all new functionality is an extension of existing functionality (or completely new functionality), we are complying with the open-closed principle.

Code Stratification

Most programmers spend more time reading code than they do writing new code. It is important, then, to write code in such a way that it is easy to read and understand.

Consistency goes a long way to help with this, but there is more to consistency than naming conventions and bracket placement.

Have you ever seen a table of contents like the one below?

  • Chapter 1. The Beginning
  • Chapter 2. John wasn’t paying attention when he modified the class. He failed to notice that the code was organized so that details of the multistep process were abstracted into a method calls. John introduced details of a new step alongside calls to the methods that nicely summarized the other steps. Fortunately, his team caught the inconsistency during code review.
  • Chapter 3. A Lesson Learned
  • Chapter 4. The Conclusion

It appears that someone provided too much detail for Chapter 2’s description relative to the other chapter descriptions.

Now consider the code below:

public List<string> GetTopTenBooks() {
    var bookTitles = GetBookTitles();
    if(bookTitles.Count > 10)
        bookTitles = SortByRating(bookTitles).Take(10);
    return bookTitles;

A method called TakeTenHighestRatedBooks that is called in place of the if-statement would hide the details of the ranking and truncation step and keep the code in the GetTopTenBooks() method at a consistent level of detail.

This is called code stratification. It is achieved when methods and classes have a consistent level of abstraction.

Company Culture: The Invisible Hand

As more millennials and gen Zs join the workforce, companies are looking for new innovative ways to appeal to a changing working class. Some companies opt to provide incentives such bonuses, gift cards, casual dress days, and even more days off hoping to spur their employees into action. These incentives, in isolation, act merely as a stimulus for promoting temporary change in the workplace but fail to foster an environment that cultivates constant creativity and productivity. Good company culture, however, acts as in invisible hand driving employees to higher productivity and a sense of pride about their job.

Before we get into all the great details of company culture, let’s consider how company policy and incentives differ from company culture, and how they can be used to complement one another. Company culture refers to the “personality of a company” and “defines the environment” a person works, whereas policy and incentives are means of achieving this culture. For example, here at Sigao, we are a people company – we believe in people first. Whatever someone needs to feel at home while at work is provided: If you can’t go anywhere without your furry little friend, bring him with you. If you eat one too many wings at lunch and feel useless, take a quick nap. If you’re like me and early morning traffic is your mortal enemy, show up at 10. Again, the culture here is what is important. Allowing pets, naps, and late starts to the day are incentives, governed by policy that reinforce the company’s culture.

I know what you’re thinking. You’re probably wondering how bringing dogs, taking naps, and starting the day at 10 could possibly be conducive to, let alone lead to higher productivity. It’s simple: people work hard when they love what they do. What’s a better way to encourage people to work hard than creating an environment where they love working? While some employers fail to utilize the power of culture within their organization, companies like Google, Apple and Sigao, of course, attract top talent from across the world not necessarily because the pay or title, but because the culture they offer makes them seem more special than a “typical” place of employment.

While you may still not believe wearing jeans makes me a better developer or playing Nintendo helps me create the most pristine algorithms, one thing we can all agree on is good company culture gives employees a sense of pride about their job. Hear me out; I don’t mean “this code is the best code mankind has ever seen, and we can push it straight to production without testing” sense of pride, I mean a feeling of ownership and significance, the feeling of being an integral part of something much more. When company culture is reflective of the people within the company, and that culture represents me, it means my voice is being heard. It makes it easier to believe in the mission of the company and feel like a part of that vision.

As we enter a new age of shifting culture, companies are looking for new ways to appeal to a younger working class while providing a fruitful environment to their current workforce. Utilizing culture within any company can be used to attract new talent while spurring employees to higher productivity and a sense of pride. Like it or not, the invisible hand of company culture is here to stay.

Culture is important to us here at Sigao. For more discussion, check out our blog post about perception of culture, and this one about why we’re here.

Introducing CreativeMornings Birmingham

This post was written by Sigao Business Development Manager Madison Hall.

In addition to being Sigao’s Business Development Manager, I’ve been working on a fun side project called CreativeMornings Birmingham! I wanted to share a little about it and the reason I’m bringing this group to our small-but-mighty city.

I’m originally from Atlanta, but after college I moved to San Diego to work for a tech startup called Lymber (which has since been acquired by Mindbody). Many of my coworkers, founders, etc., at Lymber were heavily involved in CreativeMornings.

At the first event I attended, I was surprised that more than 400 people were there to listen to Simon Sinek speak. There was free coffee from local coffee shops, free food samples from various local businesses, and tons of smiling faces! It was truly amazing how many people voluntarily showed up at 8 a.m. on a Friday morning to end their week in a positive way.

When I moved to Birmingham and began interviewing for jobs, one tough question I was asked was, “Given your city-hopping track record, how long do you plan to stay in Birmingham?” My response was that I planned to stay here long-term, because my boyfriend will eventually run his family’s company in town. The person interviewing me immediately responded with, “Oh, so you’re stuck here.”

California to Birmingham was a big move, so this kind of attitude was concerning to me. Was I “stuck” in a city where I would be unhappy?

After I started working for Sigao, my attitude changed, and I began to feel more at peace with my decision. I fell more and more in love with the city – the downtown revival, the tech scene, the restaurants, the fitness scene. I started thinking about what I could do to make this city even greater and to bring some of what I loved about Atlanta and San Diego to Birmingham.

CreativeMornings is an opportunity for Birmingham to show off how great it is on both a city level and a global level. It is held in 190 cities around the world and each city’s event is showcased on their website along with their global sponsors (Adobe, MailChimp, and WordPress). This also allows for business professionals from different sectors to connect, see how they can work together, or just start your day off with smiling faces, a good speaker, and a cup of coffee!

I encourage you to stay tuned about CreativeMornings Birmingham through their website or on our CreativeMornings Instagram (handle: CM_birmingham.)