Since the dawn of mobile applications, coupled with rise of software procurement teams, the “do we buy or build the software” question has emboldened organizations of every size and scale to evaluate uncharted territory. The question is an inevitability. That said, the context should center on clearly defined business requirements the software must meet. After all, you wouldn’t enter into a vendor evaluation without clearly defined buying criteria, expectations and needs analysis, would you?
As a builder of software and a technologist myself, it’s only natural to get pushback when it comes to a company adopting a new technology. Sometimes we hear potential customers say, “I will just build a field service management app myself.”
It is within the buy portion of the buy vs build evaluation process where a crucial series of questions is often overlooked or omitted entirely. Trust me when I tell you we consistently hear from customers that attempted to build their own field service management software application only to have it fail catastrophically. Many companies come to us because the project failed. Due to escalation of commitment, they’re now six months to a year (or more) behind schedule. While the company is busy trying to build the software, their field teams are still using paper, or their operations managers are continuing to use whiteboards, Outlook or Gmail to schedule field work. That digital transformation initiative they announced hasn’t happened. Executives at the highest level want to know where all the money went that was used to build the thing that doesn’t work and, ultimately, want to know who is responsible.
If you’re reading this blog, the responsible person could be you.
What follows are 3 key areas companies overlook in the buy vs build software decision making process. In our experience, these things more often than not account for why in-house built field service management apps fail.
#1: How Will You Update, Upgrade and Maintain the Software?
There are two types of updates to software to keep in mind. The first aspect related to updating software is the underlying operating system the software is built upon. You know when you get a software update notification on your laptop or iPhone? At every software provider around the world, behind the scenes a team is testing the compatibility of the latest update with the software they provide.
Sometimes, things don’t look right, workflows break, or things just don’t work, period. Do you have a software QA team in-house to take on the testing responsibilities? What’s more, this is a never-ending cycle of develop, test, fix/update, repeat. Does your in-house team have the capacity to effectively maintain every line of code? Building software is not for the faint of heart to undertake.
In rare events for cloud-based field service software you may need to accommodate maintenance outages. Will your software be built in the cloud or on-premises?
The second aspect of software updates is taking advantage of evolving technology. The only way to reap the full benefits of next-generation technology is to intelligently allow for future enhancements within the software architecture.
Painting yourself into a corner is very easy to do if you didn’t architect the software to be flexible as well as scalable from the start. It’s an expensive mistake that happens more often than you know. Today more than ever, field service technology is constantly evolving. Extending leading-edge capabilities to the field, such as augmented reality (AR), virtual reality (VR), Internet of Things (IoT) and others, is possible today. Moore’s law is proving itself in the field service software space as it is in the broader software market.
A super-secret third area of updates to software is if you plan to integrate third-party software, tools and systems your business uses with your in-house built software. This is usually the case when you seek to automate updates or sync data bi-directionally to said systems in an effort to avoid manual changes in response to events in the field. From time to time, APIs or other aspects require changes to the integration. This further complicates maintaining an in-house built software and one of the main reasons we discourage building the software in-house.
#2: Who Will Host Your Software and How Will You Store the Data Produced?
If you don’t know what hosting means, take it as a sign you may be in over your head. Basically, hosting is where the software you build will reside and run. You know, because the binary has to live on a server somewhere.
There is a misconception you can just run software anywhere, anytime. To some extent that is true, but it’s not the full story. Not only do you need to consider where you will host your software, but also where you will store the resulting data (i.e., work orders, asset maintenance details, customer information, field workers’ schedules) your app will produce.
Below are a few very basic questions you will need to answer about hosting and data storage for your in-house built app:
- What hosting provider will you use?
- Do you have data residency requirements?
- Do you know how to implement a scalable architecture? What about redundancy? For example, AWS allows you to have multiple availability zones by which to spread the load as well as mitigate against outages.
- Do you operate in a heavily regulated industry? If so, does the data storage system need to be compliant with specific industry regulations (i.e., HIPAA, FedRamp, PCI-DSS, Safeharbor)?
Another great question to ask during internal evaluation sessions is how much storage space you will need. Keep in mind pictures and video files take up a lot of space. Additionally, database upgrades come with the territory, so you will need to plan for unplanned releases.
Software hosting and storage come at a cost both monetarily as well as time and resources. Who on your team will carry out database or server upgrades and other hosting or data storage related activities? In your buy vs build evaluation, you need to somehow account for this activity while also including the underlying costs in your calculations.
#3: How Do You Ensure the Security of Your Software?
One of the most critical areas of architecting software is usually thought of last: Cybersecurity. Cybersecurity is not dependent on what industry you plan to use your software within; attackers don’t care, they just want the data. When evaluating building in-house field service software, you need to address security first. Your team must, at a basic level, answer how you will ensure the security of your software against hackers and bad actors.
Many organizations that evaluate building software in-house do not have a cybersecurity team let alone a comprehensive security operations center (SOC). Managing infiltration and exfiltration is a full-time job. That will not change if you build the software yourself; rather, you just signed up to take on the responsibility to secure everything—all data, user information, financial details, personally identifiable information (PII), etc.—in the event of a breach.
According to a 2019 article in CSO, the average cost of a data breach in the U.S. was $8.19 million per breach. Does your field service business have that kind of money to compensate affected individuals, customers or businesses?
A number of facets related to security must be taken into consideration during your evaluation to buy vs build software. Each facet will require careful vetting, discussion and oversight during the evaluation process.
- How will you architect the software to be secure?
- What environment(s) will you use to develop the underlying codebase?
- Who will have access to systems? How will you determine the qualifications of those who will have access?
- In section #2 of this blog on hosting and data storage, how will you vet the security protocols of the hosting provider? What about the data storage provider?
Based on the information you gather during these security sessions your company will need to derive a plan to mitigate risk. You will also need to be able to answer how your company will handle a breach.
If you can’t answer these questions, or if you do not have the internal resources to secure your app, don’t build, buy.
#4: What is Your Budget to Build In-House Software?
Chances are this is the area you have been waiting for: what will it cost to build in-house software. The answer is not simple, but I will try to distill it down into categories of cost considerations.
No two apps will cost the same to build. Software development is an ever-evolving market, so don’t quote me on these.
When determining a somewhat accurate estimate for what it will cost to build in-house field service software, there are many, many costs you need to take into consideration.
Cost Consideration #1: Hiring (and retaining) software developers
Every software company needs software developers (usually a team of them) to build the software. Over the past five years or more, you have probably read a number of articles about how expensive it is to live in locations like Silicon Valley, Seattle and Austin. Namely, the rise in cost of living is directly correlated with the rise of technology; software vendors in particular.
The question is, who do you hire to develop the software? How much do you pay them? Do you get the best or good enough? What will it cost you if one or more developers accepts a new position elsewhere?
There are so many considerations when it comes to what will be included in the software and how it will work, but very little attention as to who will build it. It is no secret software developers are in high demand—everywhere. That demand comes with high expectations as well as a keen interest in what they’ll actually be working on. What makes your software project compelling?
Software developers in all their forms come at a steep price because they are in such high demand. Do you have the budget to hire great software developers, architects, and engineers? Keep in mind your budget will have to include excellent benefits, company stock, flexible work schedules, development tools, and a high salary.
Consider costs related to retaining the talent you hired as well.
Cost Consideration #2: Total cost of ownership
Including hiring developers, software is not one and done. It is rare when a piece of software is developed and remains the same over a year’s time span even. What if your team needs a new feature? What if a database needs upgrading, or security protocol requires an expanded package to run with your version of operating system?
From updates to maintaining servers or hiring additional talent, the total cost of ownership can be quite extensive. I usually estimate you can expect to spend at least one to two times the original cost to maintain the software after you’ve built it.
Enterprise software is usually in the high hundreds of thousands to over a million and beyond. If you build a field service app in-house, depending on what you need vs what you want in the app, you could spend half that easily.
If you are still considering building field service software in-house you may quickly come to the realization that it’s simply too expensive to undertake. There is a reason Field Squared exists, after all.
We built the Field Squared Platform to be a highly configurable, enterprise-grade software so you don’t have to.
Leave the development to us while you reap the benefits across your field service operations.
Want to learn more about field service automation?
Watch our 60-second demo video to quickly show you how Field Squared works. View it below.