Build vs Buy Framework for Field Services (4 Key Criteria)

You can save your field services team 100s of hours in labor and associated costs by implementing technological solutions that automate the flow of data between systems. 

However, teams often need help deciding between building or buying those solutions. 

The truth is that “build or buy” isn’t a universal decision that applies across your organization. You need both approaches. The challenge is determining which path forward is best.

Making the right decision comes down to a framework. 

While many build vs. buy decision frameworks are out there, they’re not specifically designed for field services teams. Using our experience in the industry, we created a unique framework to help you make the best decision based on four key criteria. 

We’ll show you what happens when build vs buy goes wrong, the framework needed to avoid those pitfalls, and examples of how to apply it.

When Build vs. Buy Goes Wrong

The wrong build vs. buy decision can drive progress back for your entire field services team.

For example, we saw a team without strong in-house product development or technical project management competencies outsource development to an offshore firm. The organization lacked the internal competency to ensure the product aligned with the business needs and development didn’t sprawl. In the end, the project took 4x longer than expected.

Another team picked an out-of-the-box tool without evaluating the business needs. Months later, they realized that the application created several workflow gaps. Rather than save time, teams struggled more.

Both organizations missed out on months of potential value generation.

Choosing between building or buying isn’t easy, and the stakes are high. However, you can avoid setbacks by evaluating each use case with the proper framework.

Build vs. Buy Field Services Framework (4 Key Criteria)

Each workflow in your business has specific requirements that a solution must meet to ensure the maximum benefit for your business. To help our clients make the best decision, we created a simple process for evaluating each use case.

Ask these four questions to help you decide whether to build or buy:

1. How unique is your business problem? 

Out-of-the-box solutions work well with standard workflows, such as HR onboarding or invoicing. However, a process may be too unique (with too many exceptions) to solve effectively with a turnkey solution.

If you can quickly and easily solve the problem with a SaaS tool, consider buying it. If you have unique workflows or need to solve a problem in a way that hasn’t been solved before (to generate a competitive advantage), consider building the solution. 

2. Do you have internal product development competence? 

Technical competency refers to your team’s skills, knowledge, and experience with technology. Regarding build vs. buy for field services, we’re referring to the skills needed to assess, build, deploy, test, continuously improve, and maintain solutions in the field. 

Your team’s tech competency will fall on a spectrum. You’ll excel in some areas and have skills gaps in others. No team can master them all. 

If your team lacks strong product development competency (they don’t know how to research, innovate, design, develop, prototype, and launch a solution), you should consider buying or building with a trusted partner. If they have that skill set, you should consider building.

3. When do you need a solution implemented?

Tech teams frequently spend most of their time maintaining systems and ensuring delivery. They’re frequently swamped with tickets and struggle to find time to innovate.

If your internal team’s roadmap is longer than six months or you need a solution immediately, consider buying or building a solution with a trusted partner. If your team’s roadmap is less than six months, consider building the solution in-house. 

4. How much control do you want over the product roadmap? 

When you buy a solution, you rely on the vendor to maintain and advance the platform. When you build a solution, you control feature development, data, and maintenance.

If you don’t need to control your product roadmap and development, consider buying. If you need to control your product roadmap and development to better fit the needs of your customers and/or business, consider building.

To put this framework into context, here’s how we helped two of our clients in the field services space evaluate and choose between build vs buy based on the above criteria.

When to Build a Custom Solution

One of our clients delivers industrial, medical, and specialized gasses across the US. Before their drivers leave the depot, they inspect their vehicles and file a report. This ensures the safety of their team and the materials throughout the delivery.

It was a very thorough, paper-based process. Drivers inspected the vehicles, noting any damage, mileage, weird sounds, etc., and sent the paper report to headquarters.

Scaling Inefficiencies with Out-of-the-Box Solutions

The team wanted to transition from a paper-based solution to a digital one. They didn’t think their problem was unique, so the team shopped around for an out-of-the-box solution. It didn’t take them long to find and deploy a SaaS tool that created mobile forms, stored them in an app, and allowed their drivers to fill them out.

While the tool did a decent job initially, they saw challenges as soon as they tried to scale the process across the organization. Mainly, the solution forced drivers to jump through hoops while inputting inspection data, reducing the benefit of digitizing the process.

The app worked, but not perfectly. It was death by a thousand papercuts. 

For example, the process flow for updating the data was very time-consuming. Users had to exit the app and sign back in to see the new data. Additionally, the application stored the collected data in PDF format (not structured data that could be actioned). 

It was a headache.

The team needed more control over data collection and movement between systems.

The Need for a Unique Solution

To make the tool work, they spent time and resources modifying on top of the tool so heavily that it made more sense to build a custom solution.

Taking a step back, they realized that their challenge was unique. Unfortunately, they couldn’t see this until they got into the weeds with the application. 

That’s common with tech. 

You discover a business problem. Test a solution quickly. See if it works. Then, decide whether to continue using the application or choose a different path. It’s an agile approach and not necessarily the wrong one.

This wasn’t a failure for the team. It helped them transition from paper processes to digital ones, which is a huge win. But it wasn’t the ideal state. 

Still, they thought through the workflow and started taking steps to improve it. Their efforts put them on a path for continued improvement.

Transitioning to a Custom Tool Despite Product Skill Gaps

Technology teams in field services often lack a deep product development skill set. That’s understandable because they focus primarily on delivering products and services to their customers—they’re not trying to be a tech company.

As a result, they often settle on a SaaS platform that isn’t a great fit. Or, they find a consultative partner who can augment their skillset and build that solution.

In this case, we worked with the business to build a custom solution over 3 - 4 months that fit the exact needs of their inspection workflow. The custom app easily collects and refreshes mobile data without internet connectivity issues. 

Even better, they use the data from the inspection report to take trucks offline for repairs (something the SaaS tool couldn’t do). For example, a truck will no longer be available for selection if a driver reports a strange sound and the vehicle gets flagged for maintenance.

Now, we’re looking to expand the application's functionality to include features like predictive analytics to help them better time vehicle repairs.

When to Buy a SaaS Solution

Sometimes buying is the better option. 

We worked with a national stained glass company that repairs and installs stained glass for churches nationwide. Their sales team primarily visits churches, takes pictures of the windows, and provides recommendations in a proposal. 

The team didn’t have a CRM. Instead, they used a legacy, homegrown proposal system to manage the process. And they wanted to collect more sales data to improve the proposal process. Their team met with us to determine whether they should replace their proposal system with a custom CRM. 

Most CRMs have extensive base functionality. While some may have unique features or better integrations, many have the same capabilities. There are numerous affordable options available. 

For the same reasons you wouldn’t build an accounting system from scratch, most companies don’t need to build a CRM from scratch. It’s a lot of work, and the overall benefits are minimal compared to the level of effort and resources. Plus, this was a small business with limited resources.

Choosing to Buy Over Build

Our team’s recommendation was to buy a CRM and integrate their homegrown proposal system into the application. While the CRM use case was common, the organization’s proposal system provided unique value to the business because it gave them extensive flexibility in that workflow. 

Ultimately, this was the best decision for the business. 

The proposal workflow was the unique use case, not the CRM. Integrating the proposal system with an out-of-the-box CRM solved the problem. Additionally, the team didn’t need to control the project roadmap for the CRM. They needed control over the proposal piece, which they achieved by maintaining that system.

This was also a smaller business without a skilled IT product development team to build and maintain a custom solution. They relied on us to fill those gaps and guide them. 

The project finished quickly because they needed time to implement the CRM. While they worked to deploy that tool, our team built out the integration. 

Buy was the best path forward for this specific business issue.