Build or buy? The custom software question

By the time we’re in the room together, most of our clients have been grappling with the build versus buy question for a while. It’s pretty common that they’ve completed an exhaustive search and have decided: build. They’ve seen what’s available off the shelf, didn’t like it, and hired us to make something custom. 

It’s still our company culture to probe why they want to build what they’re building. We’re committed to delivering goal outcomes in the smartest way possible — and it’s not unheard of for us to steer teams away from the precise build they pitched us. Let’s take a look at two examples. 

Example 1: The Farm — Can we make off-the-shelf software work? 

In early 2020, we were introduced to one of the nation’s leading growers and processors of fresh vegetables — we’ll call them The Farm. The Farm was consistently launching new products under their consumer brand, and they’d recently documented their R+D process. Now, they needed to turn that documentation into a day-to-day project tracker. 

In other words: they needed a web app.

Building a custom app from scratch wasn’t The Farm’s first instinct. They were thinking they’d go with an off-the-shelf solution like Sharepoint. But then, two things became clear. 

First, while they could absolutely customize an existing platform to do most of what they were looking for, there was no perfect fit. To make it work, there’d be workarounds and some bandaids. A custom build was the only way they could get precisely what they needed for their unique process.

Second, The Farm also discovered that the difference in price wasn’t prohibitive. Yes, custom will always be more expensive out of the gate, but once it is developed, a custom app is yours — no licensing fees and limited maintenance costs. 

Verdict: Build

Outcome: The Farm is anticipating only a 3–4 year pay-off period for a platform that’s tailored to their exact specifications, and can continue to be honed and improved. After a four month build, their custom project management tool was implemented and The Farm’s R+D team increased their productivity by 50%. Victory, indeed. For more on this project, check out our case study

Example 2: Taco Time — Should we build an app? 

Taco Time asked us to update their global site with a custom web app for franchise owners to order uniforms and employee merch, as well as manage their locations’ store hours. They were right — they did need custom work, but their needs didn’t warrant the budget for a full-on application. We could simply build a custom plugin on their existing WordPress instance.

Verdict: Build — but a make it a plugin

Results: We’re proud of Taco Time’s feedback — it reflects our company culture completely. In their words, “Understand what you need and be honest and transparent about what you’re trying to accomplish. If you’re clear about that, Bilberrry will be clear about what they can and can’t do and they will suggest strategies for getting where you want to be.” 

How build and buy stack up


  • Requires development time
  • Developed to your specs and requirements
  • Documentation and training need to be built
  • Cost often underestimated up front — for an accurate estimate make sure to include: initial discovery, design, build, test, implementation, and lifetime support costs like added headcount, patches, maintenance, enhancements, and upgrades
  • Easily scalable and replicable — often very cheap (or free) to add new users or scale 
  • Pride of ownership: It’s ours, built just for us
  • May not be necessary
  • Feedback and testing process is very hands on
  • Requires ongoing willingness from the org to continue supporting the product


  • It’s already built — no waiting!
  • Likely customizable, but not custom
  • Ready to use once installed
  • User documentation, training, and support likely already exist
  • Cost is set and includes support
  • Future upgrades may cost more
  • Pay to scale, often per user, per file, or by storage
  • Procurement process can be elaborate and time-consuming
  • In-house team still has to perform discovery
  • An adequate product might not exist


Want a sneak peek into what a Bilberrry discovery sounds like? These are all the questions we ask when we’re making a build vs buy decision, for ourselves or alongside a client. For both, the ultimate goal is for everyone to use it and love it. Here’s how we start to figure out which is the best option.

Need and outcome

  • Will a custom solution provide you with a competitive advantage?
  • Is there a strong need for deep customization? 
  • Is this solving an acute set of issues or is there a vision for this to evolve larger to address more and more of the business needs? (For example, Is this going to just be a manufacturing calendar or eventually a full ERP?) 
  • Is there a market/need for this tool outside your organization? If it turns out to be successful in your org, would it make sense to license it to others or turn it into a SaaS product?

Existing solutions

  • This may be an obvious one, but it’s worth asking: Does this software already exist? Have you tested or piloted any off-the-shelf solutions to address the business need? If yes, where did those go wrong?


  • Is this a long-term need and solution for your business?
  • How frequently do you anticipate the business requirements/feature requirements changing?

Mitigating risk

Internal resources and support

  • Are there business goals and clear success metrics for this investment that will help you justify the cost, time, and internal hours that will need to be invested?  
  • Is there broad consensus/buy-in at the organization that this is a high priority need, among both leadership/decision makers and intended users?
  • Is there a change management/user adoption plan? What are the foreseeable risks? 
  • Do you have internal resources who understand software development? (This is not always needed, but makes it a lot easier to make strong strategic decisions.)

Timeline comparison

  • How urgent is the need? 
  • How does the deployment time for the existing solution compare to building custom V1? Off the shelf might not be perfect, but it might be available now. Your V1 also won’t be perfect, but it’ll be available sooner than V2. 
  • How do the ongoing annual costs of use and support compare? You’ll need to take into account the recurring cost of an off-the-shelf option and the ongoing hosting & maintenance of a custom built app. 

Cost comparison 

  • How do deployment (implementation/customization) costs of the existing solutions compare to the custom build?

Our POV: We love to build software and we love ready-made solutions, too

There’s no one right answer to the question, Build or buy? The right answer is case specific. In our minds, it’s the end goal that matters: your team using software that works for you. That software should be intuitive, useful, and you should love using it. It needs to be within budget, and well-supported. The how — either we build it, or we help you find it — is far less important to us.