How to avoid costly mistakes while buying custom software

Woman frustrated by costly mistakes

As providers of software development services, we encounter clients from a wide variety of backgrounds and industries.  All companies, from startups to mega corporations, have business problems that can be solved with technology solutions.  However, software development is a wildly complex skillset that is often made less comprehensible by ever-evolving jargon and practitioners who are only familiar with talking amongst other practitioners. This leads to a massive knowledge imbalance between buyers and sellers, which in turn opens the door for unskilled teams to take advantage of unsuspecting buyers.

Over the years we’ve heard countless stories of buyers having bad experiences with their software projects (in fact, we’ve helped fix a couple of those projects!).  Whether its buying software that isn’t needed, entering into unfavorable contracts, or simply not being aware of the expenses involved with a project until its too late, the buying process is filled with potential pitfalls that can affect the overall success of the project.

Because of this, we’ve decided to provide an educational guide for buyers.  This should not be considered a comprehensive checklist, but instead a starting point for further research.  Our goal is to help prepare you for what to expect, what to ask, and what you should know to avoid making costly mistakes.

What should you think about before starting the process?

Many potential buyers have not fully considered what building and owning a software system means. This is a big undertaking with big ramifications for your business. Take a few minutes to consider the following pitfalls and misconceptions that new buyers deal with.

Software is expensive

This is the number one thing that most people are surprised by when they first start looking into a software project.  The skills required to properly build a software application take many years of constant training and dedication to refine.  What further complicates this issue is the relatively low barrier to entry.  Virtually anyone can take a few free courses and call themselves a developer, and many people do.  As the market saturates with new, inexperienced developers, it leads buyers to assume that it’s an easy/common skill set that shouldn’t cost much.

Worse yet, lower skill developers typically focus on skills that produce visually appealing, user facing code, while not training on how to scale large applications.  This means that buyers often don’t realize their software is broken until they attempt to onboard users and their money is already gone.

 It can not be overstated how often we encounter buyers with broken code bases and empty budgets looking for a quick fix to system that is beyond saving.

While the lure of cheap developers is a powerful one, keep in mind that the vast majority of projects made by low skilled developers need to be scrapped.  While prices can vary wildly based on geographic location, a typical US based proof of concept project will run anywhere from $50,000-100,000. Hourly rates for talented on shore development firms will likely be anywhere from $110-185/hr, and potentially higher for teams that provide DevOps engineers and have enterprise software experience.  Talented developers are worth their weight in gold, and their salaries reflect that.

Think of software like building a skyscraper.  Low-cost developers have learned how to poor cement, place rebar, and decorate a pretty facade, but don’t have extensive training in large scale mechanical stresses, foundation design, and resource management.  The building will look fine for a while, but as it grows the cracks will show and eventually it will fail and need to be rebuilt.

Not all languages and frameworks are equal

Every development team has their favorite programming language and frameworks, and they will likely give you reasons why you should allow them to build with that language or framework.  While it’s true that most code behaves in roughly the same way, your job from a business perspective will be to support this application long term.  That means your project needs to be written in a language that is popular, and likely to be around for a while.  The developers may love a new fad language that’s just “so much better” than the older languages, but if the new language dies out in six months you now have to A) stick with that team forever, or B) find some other shop using this niche, probably expensive language.

We encourage you to research application languages and frameworks on your own, but this 2021 Stack Overflow survey is very helpful.

Your business needs should be defined

Think long and hard about what problem you’re solving and how much money you’re losing by not solving it.  You don’t have to know HOW software will fix the problem, that’s for the development team to figure out, but you do need to know WHAT problem you’re fixing and how much money that fix will save you over time. 

If the team doesn’t actively understand and work towards solving your business problem, get a new team.

On the flip side of this, understand that business problems have a lot of solutions, and the most appropriate solution may not involve the specific technology you have in mind.  Our team regularly encounters buyers who insist that they need an app yet describe a business problem that does not fit a mobile app delivery model.  The best project outcomes occur when business experts focus on business problems and technology experts focus on the best technology to solve those problems.

Software projects don’t end

This is another misconception that tends to blindside buyers.  Most people assume that a project will start on a specific date, run for a specific time, then end.  But the reality is that software expenditure ends when the problem no longer needs fixing.  At a minimum, the software will incur monthly hosting and maintenance costs.  You cannot leave modern software without maintenance because there are so many connections to other applications that any number of external factors can destabilize your system.  Your system will need to be actively monitored and fixed as errors occur.

However, errors aren’t the only things to consider.  Most projects end up identifying other business issues beyond those originally in scope. Virtually all businesses have an ever-increasing backlog of business problems to solve, each with a corresponding increase in revenue or decrease in expenses.

If the business problems are being solved properly, the economical solution is to continue development indefinitely.

You MUST be hands on

Custom software products are, by definition, creating solutions to non-standard problems.  If the problem were standard, there would already be a software product available to solve that problem. That means that the quality of your solution will depend entirely on how clearly and frequently you can communicate your business problem to the development team.  Nothing predicts negative project outcomes like buyers who are not willing to be involved with their custom solution. 

Think of it this way, if you had an idea for a brand-new car that doesn’t behave like any car in existence today, would you assume that you could describe it to engineers one time and then come back in a few months and have the perfect car? No, you would need to constantly discuss the new functionality you want and sign off on changing the functionality that may not be possible.

Common terminology all software buyers should know

Knowledge of common development terms can greatly increase your understanding of the project, as well as the competency of your potential development partner.  There are nearly endless development terms, but we’ve done our best to choose those that most apply to team’s ability to produce quality work.


Agile is a software development philosophy that focuses on iteration, quickly assessing new information, and changing directions as needed.  Methodologies that use Agile principles are proven to result in better project outcomes over a shorter timeframe.


This term is used to encompass a wide range of activities surrounding the successful operation of development teams.  DevOps is concerned with making sure code is deployed consistently, with minimal bugs, and with many contingencies to prevent system failures.  Robust DevOps practices are mandatory for large, enterprise applications.


In software development, the “environment” typically refers to an instance of the system that is set up for a specific purpose.  Environments allow the engineers to change specific variables for various stages of the development process.

Development Environment

This is where engineers modify and expand code.  Development environments are typically unstable due to large scale changes, and 3rd party integrations (particularly those that charge money) may be disabled.

Test Environment

This is a more stable version of the system where manual testing can happen.  It’s built to simulate what active users would see and is generally more stable than the development environment.  3rd party systems may be active at this stage to fully simulate the user experience.

Production Environment

This is the version of the system that users see and interact with.  It contains live data and outages are considered critical.  No changes should be made directly to this environment without first going through a review and testing process.


Scrum is one of the most popular methodologies that uses Agile principles.  In this methodology, the team commits to a set amount of work in fixed periods of time called “sprints”.  The work is then evaluated, and a new set of work is chosen for the next sprint based on the results of the previous one.

Version Control

Technology used to update the code base in a controlled and reversable way.  Code bases that are version controlled can easily be “rolled back” to a previous version if a mistake is made. Virtually all modern code repository tools will use some form of version control to protect the code base.

Automated Testing

Software systems are wildly complex and contain too much functionality to test manually.  To deal with this, engineers write small pieces of code that test the functionality of the code that comprises the system.  These tests run periodically and let the engineers know if any of the system code changed in a way that broke functionality.  When that happens, a report will tell the engineers where the failure happened which lets the system be fixed much faster.  Below are some examples of specific types of automated tests.

Unit Tests

Tests designed to validate that individual “units” of code still run properly.  For example, a unit test may validate “XYZ unit of code always generates an even number”.

Integration Tests

These tests ensure that large modules of functionally within the system behave properly when combined. For example, an integration test may validate “Module X and Module Y do not product errors when run together”.

End-To-End (e2e) Tests

These tests simulate a user in the system by testing functionality from the standpoint of the UI.  While these tests more accurately represent the real-world usage of the system, they are more expensive to build, slower to run, and more difficult to change. Because of this, engineers may choose to use them sparingly. An end-to-end test may validate “When the user clicks on X page element, the page navigates to Y page”.


A place where all the code in the application is stored and updated.  Typically, this is cloud hosted and accessible anywhere.


A sprint is the period of time in which a team will work on a set amount of work.  Sprints periods are anywhere from 1-4 weeks, however 1-2 week sprints are generally considered the most productive.

Test Driven Development (TDD)

Test driven development is a coding practice in which engineers write the automated tests before writing the functionality.  As the functionality is being written, the automated tests will continually tell the engineer if the new code is correct.  This is generally considered a more advanced technique but results in extremely well written and tested code.


The way in which individual lines of code are written. Similar to traditional human languages.

Continuous Integration and Continuous Development (CI/CD)

CI/CD is a series of automations and activities designed to move new pieces of functionality through a “pipeline” of validation and testing before ultimately being deployed for users to experience.  The CI/CD process is one of the primary concerns of a DevOps practitioner.


A collection of pre-build functionality, written in a specific language, that encourages developers to build a system using known patterns.  For example, applications using the Angular framework are written in the Typescript language.  The Angular framework provides pre-built tools, written in Typescript, that only work properly if used the way the Angular framework developers intend for them to be used.  Frameworks allow teams to move much faster, but occasionally present development challenges if the project calls for functionality that the framework does not support.


All systems experience errors, regardless of how much automated testing is done.  When these errors happen in production the system needs a way of reporting what went wrong, when it went wrong, and who was affected to the development team.  Monitoring software is installed within the system code to generate these reports and send out alerts when critical errors happen.

Tech Stack

The “stack” refers to the collection of technology used in each of the layers of the application. An example of a tech stack would be “Angular, .NET Core, and SQL” which means that the front end of the application would be written in Angular, the API/middle layer would use the .NET Core framework, and the database would be a SQL database.

Front End Layer

The “front end” refers to the technology used to produce the part of the system the user sees and interacts with.  This can refer to website tech or mobile app tech. 

Middle Layer

The middle layer or middle tier is the part of the application that acts as the “brain” of the system.  It makes decisions about what information is sent to the front end, how information is transformed, and what information is sent to the database.

Storage Layer

This layer houses data long term.  When a user makes a request via the front end, the middle layer interprets this request and retrieves data from this layer.

Key questions for potential partners

Questions are an absolutely vital part of the process. With the success of your project riding on both parties understanding of each other’s needs and capabilities, the only “bad” question is the one not asked. We’ve provided some example questions to get a feel for your partner’s capabilities, but we encourage you to think of more and ask away.

“Will I have access to the team’s planning tools?”

Teams should be using some sort of centralized place for organizing the current work (essentially a group TO DO list), and you should have access to it.  You are paying a lot of money and you deserve to have work visible to you.

“How will I check the quality of the work during development?”

Again, work needs to be visible.  If you do not have a way to test or view the system than you cannot confirm that the correct work is being done.  Rewrites are expensive.  Its your job to provide rapid and frequent feedback, and it’s the development team’s job to make it easy for you to see your system.   Most firms should create a test environment for you to play around with as the system is built.

“Will I have access to the repository?”

Its your code.  You paid for it, you own it, and you should have access to it.  Larger, more established firms may simply write into the contract that you own all the code and provide access as needed.  However, if you’re dealing with freelance engineers, or otherwise less established businesses, always ask for admin access to the repository so that you can remove users and retain your code.

“Who owns the IP of the code generated, and is it specified in the contract?”

This is a highly complex issue that will likely require further research on your part.  However, in general you will want to make sure that the code used in your system is either written by your team or open source and legal to use free of charge.  You will also need to make sure that all code written by your development team is completely and totally owned by you forever.

“What is your preferred tech stack?”

They should be able to answer what their preference is, as well as if they’re able to use other technology beyond their favorites. Do your research on the technologies they use and try to avoid niche languages and frameworks that may hurt you in the future.

“What is your automated testing process like?”

At a minimum they should use unit tests and LOTS of them.  The more they can speak on testing the better.  Companies that use unit, integration, and end to end testing while practicing test driven development will likely produce extremely high-quality code but will be more expensive than other companies.  In general, automated testing slows development up front, but saves huge amounts of money long term.  If your project is quick and not very complex, you’ll likely be ok without much automated testing.  If you intend to build large, enterprise system, testing is a must, and your development partner needs to be capable of building those tests.

“What is your CI/CD process like?”

Ideally the process will involve a test or staging environment that is not public.  Releases should be frequent and automated tests should run as part of this process.  This process should also provide a quick way to revert back to previous versions of the system in the event of a critical error making it into the production code.

“What is your work methodology?”

Good processes are arguably one of the most important determining factors in the success of a team.  If a development partner cannot accurately describe the process by which the team completes work, you can bet that development will be slow and poor quality.  Amongst defined development methodologies, Agile centric methodologies have been proven to be the most effective as they promote strong communication, frequent evaluation, and rapid adaptation to new requirements.   

Did you get all that?

This is a massive topic and unfortunately this ridiculously long blog post doesn’t even scratch the surface. However, we hope that this information was thought provoking enough to serve as a starting point on your journey, and to help you feel more confident and more capable of working with a team.

At Sigao our mission has always, and will always, be to leave our partners better off than before they met us. If you have any questions about this topic, feel free to comment below or give us a shout directly.