Should You Buy or Build Your Own Software? 7 Key Questions

Say your organization needs to resolve a problem and it’s clear you’ll either need to find an existing software solution or create your own. Deciding which path to take can be a serious challenge, with advantages and disadvantages to either approach.

The following questions, focused on building custom software from scratch vs. investing in software as a service (SaaS), are designed to help you make the best choice for your organization’s unique needs.

1. Should you rent your home or build new?

The conundrum of whether to buy existing software or build your own is not unlike choosing whether to rent a house or build one yourself. With renting, you should come to occupy a ready-made, comfortable space with standard amenities and little to no responsibility for repairs. If problems arise, you call someone to take care of them. More often than not, you can move in quickly, make relatively low monthly payments, and commit to no more than a year at a time. For the convenience, you’ll likely sacrifice the ability to remodel, make personalized cosmetic or structural changes, or purchase the property.

When you build your own home, you start from scratch and every decision is yours. The investment will be large initially (including the purchase of land) and unless you have a bevy of technical skills, you’ll need to either hire help or learn, for example, about electrical systems. If something goes wrong in the building stage or a problem appears (one you either didn’t catch early or that arises later), the fix is up to you. You won’t move in until everything is complete, which will likely take some time, but the property will belong to you completely until you decide to sell it.

The choice involves a variety of considerations but mainly it’s about what your needs are, what resources you have, and how quickly you need to be under a new roof. Just like selecting where you will live, when deciding whether to buy software or build your own, it’s important to take time and weigh the options.

2. What type of problem are you trying to solve?

A vital first step in determining whether to build or buy is assessing the issue(s) you’re attempting to resolve. In determining this, the following considerations can be useful:

  • Is this issue specific to a small area of your business or does it have larger-scale ramifications?
  • Is solving this problem a matter of vital importance or convenience? What is the urgency?
  • How often will you rely on a solution to this issue? Daily, monthly, annually?
  • Is there a solution to this problem on the market or is it unique to your organization?

Exploring pre-existing solutions to determine if relevant options currently exist (while also assessing price, features, and flexibility) can help you assess whether your problem can or should be solved without building.

3. What technical assets do you already have?

Once you’ve studied the scale of your issue and what, if any, solutions are available, you’ll want to assess your current team and resources.

Do you have IT or development professionals capable of building a solution for you? You’ll need to consider their technical skills (and the specialized vs. general nature of the knowledge required), current workload, and future commitments. If team members will need additional education, training, or unrestricted time for your solution, how receptive will they be to this and how much of each will they need? If you choose to build without ensuring adequate skill level, the results will likely be unsatisfactory.

And don’t forget about supporting technology. Do you have the computing and engineering tools, plus server capacity, your solution will require? If you don’t already possess the people and equipment required to build, you’ll have to procure them.

4. What will the resources, costs, and time involved be for either option?

Making the choice to buy or build is all about comparing your options.

  • Will you need to acquire new technology or personnel to design, implement, and keep-up your solution?
  • How do these costs compare with a ready-made or even customized software solutions on the market?
  • What kind of paid employee or outside contractor time will your solution require (consider development, deployment, training, support, and maintenance)?
  • How long will you wait before your solution can be deployed?

In very general terms, buying SaaS software tends to be cheaper than building. According to Atomic Object, you can make a rough estimate of costs involved in custom-built software by multiplying the price of an off-the shelf solution by ten. Choosing to buy also means you should be able to implement a solution faster, save money on technology (especially considering Cloud storage), and conserve staff and contractor hours.

As an example, the Submittable team has spent nearly 10 years designing and improving upon a submission and application management system; most organizations can begin using it in under an hour with very little to no training, our developers maintain the software, and our servers handle the data. Basically, if you need this type of solution, you don’t have to solve a problem that’s already been solved—you can focus elsewhere.  

5. How will your solution integrate with current software and processes?

Regardless of the choice you make, your solution will have to be incorporated into your organization’s regular procedures. Adapting to new systems will likely require adjustments for both your team and your tools. You’ll want to be sure that all relevant personnel have access to the solution (whether this requires an internet browser or hard drive installations)—they’ll also need time (and likely training) to adjust to new work routines. The more complex the solution, the more consideration you’ll want to give this.

Your new platform will require integration with other software you already use. If you decide to purchase, many SaaS platforms like Submittable use Zapier to facilitate seamless data exchange. If you opt to build, keep in mind that each update to software integrated with your custom solution may require an update on your end.

The necessity of an integration process for new solutions (bought or built) also speaks to the value of flexible software (and less software at that) which can be used for multiple tasks and across departments, thus reducing the number of tools you have to worry about connecting.

6. What kinds of training, support, and maintenance will your solution require?

If you’ve decided to build, what sorts of training will your technical team need to determine requirements, configure and generate code, test the product, integrate software, and adapt as issues arise after the solution is deployed? What about training needed for other team members that will be using the tool?

Should you decide to buy software, research available help and training resources, and estimate how much time your team will need to receive instruction and get acclimated to the new system. Customarily, the more complex the system (vs. the one you already use), the more training required, for both building and buying.

In addition to preparation for your own team, you’ll also want to prepare to assist any external users. In the case of submission management systems like Submittable, people using the software on the front-end may need just as much support as those using it on the backend—for this reason, we provide robust support services for both parties, saving organizations from the hassle of responding to submitter questions. If you build your own solution, you should plan to dedicate your own time and resources towards offering technical assistance for external users.

Investing in a SaaS platform nearly always means that updates and fixes will be automatic and included, since the software company should have team members exclusively dedicated to this endeavor on an ongoing basis. Ideally, they will advance and improve consistently based on user feedback.

Building your own system means that all modifications will be your responsibility, as well as bug fixes and the solicitation of feedback that should inspire future enhancements.

7. How integral is the solution to your long-term goals?

Consider your larger company objectives and how important this solution is to achieving them.

  • Do you need this new solution to be competitive?
  • If you are looking to expand your business, will the system be scalable?
  • Do you foresee needing extra flexibility and customization in the future?
  • How does your solution fit with long-term budgetary goals?

This is also a good time to assess potential risks.

  • If the chosen solution doesn’t work for you, how much time and money will you have lost?
  • How easily will you be able to extricate yourself in the case of dissatisfaction?
    • Did you sign a contract?
    • Did you make a commitment to employees or contracted workers?
    • Can you return purchased technology?
  • What resources will be required to purchase or build another system after the fact?

Selecting a known solution that offers flexible terms may feel more secure than the unknowns involved with a custom-build. Still, if you need a highly specialized system that you own to be competitive in the future, a solution for which no market equivalent is sufficient, then building may be worth the risks involved.

Whichever route you ultimately choose, your decision will have lasting financial and organization consequences. For this reason, taking the time to thoughtfully consider the pros and cons of buying versus building a software solution is vital before you take the leap.

Interested in Submittable’s off-the-shelf and custom SaaS solutions for application and submission management? Please reach out anytime.

Rachel Mindell

Rachel Mindell is a Special Projects Editor at Submittable. She also writes and teaches poetry. Connect with her on LinkedIn.