Internal Tools: The Ultimate Build vs Buy Guide (2023)

Build vs Buy is often a grand debate in internal tooling, where SaaS products are incredibly prevalent and often brilliant (think Slack, Zendesk, Salesforce) but often just a tad too generalized to fulfill all companies’ needs. In this article, we’ll run through some of your options, how to decide when to build or buy, and the pros and cons of each option, to help make your decision a little smoother. 

‍

Let’s jump in. 

‍

‍

What options do you have when buying or building internal tools?

‍

Let’s start with some definitions. Firstly internal tools. Internal tools are any app or automation that is used to conduct business activity, including communication and task management, without the tool being customer-facing. 

‍

You could buy an out-of-the-box SaaS product if you are looking for something pre-built, that won’t need much customization. Think platforms like Slack, or CRMs like Salesforce. These are usually quick to onboard and implement, but lack the ability to change what’s under the hood.

‍

On the opposite side of the spectrum, in the ‘build zone’, if a SaaS product didn’t meet your needs you could custom code from scratch the traditional way. That is to say - code the entire app from back to front in a language like JavaScript or Python, or using a library like ReactJs. This results in the most bespoke product but can take weeks and months to complete, and needs constant maintenance from an engineer.

‍

Now we have some new players in the ‘build’ game too: low/no-code platforms, and developer-focused tools. Low/no-code platforms are a growing trend in all spaces of development, and also in the internal tool sphere - they are typically proprietary platforms that abstract the complexities of code with a visual language that allows even non-technical users to make their own apps and/or automations after a bit of learning. Some examples include OutSystems and Bubble for internal tools and Zapier and Make for automations. We also like to add Google Sheets, Airtable and Notion to this category too.

‍

Where low-code and no code tools focus on enabling non-technical employees, Developer tools focus on expediting development time for technical employees, abstracting some of the code into simpler functionality. They do this predominantly by pre-packaging common functionality and code, like permissioning suites, authentication, and common components like tables or buttons. into a simpler UI, while still maintaining as much customizability as possible with code. Top players in this space include Retool, Django Admin, and Ruby on Rails (the latter two are language-specific). 

‍

‍

To buy: when are SaaS products, or out-of-the-box solutions best?

‍

SaaS or pay-per-use products are generally premade pieces of software designed specifically for common use cases and/or targeting specific departments. Many of these products are ubiquitous within their industries - think Slack for messaging, Salesforce or Hubspot for Sales teams, Zendesk for support tickets, and Linear for engineering tickets.

‍

Now, for all the disjuncture they may sow amongst opinionated employees and developers alike, there is certainly a place for SaaS products in the workplace, and just because you have the resources to build a tool from scratch, it doesn’t always mean you should.

‍

‍

‍

So when should you buy? 

• When the budget is too small. Many SaaS products offer affordable or even free tiers that are inevitably quicker and cheaper than a custom app. If your company is just starting to test the waters, this may be a good time to make do with a ready-made product, until a point when you can afford to scale up and customize. 
• When you want to know what other companies are doing. Out-of-the-box SaaS products are a great way to scope out how competitors’ systems work. Chances are, when purchasing a SaaS product, the company providing the service has studied their customer attentively, or has themselves faced the problem in order to make its solution. SaaS products can provide a great MVP to test out potential options and get an idea of what your system generally should look like. 
• When you aren’t sure you really need it. Some internal tool ideas might sound like game changers… until you build them and realize that perhaps they aren’t all they cracked up to be. As above, if you aren’t sure if you need a tool, start with SaaS as your MVP.
• If you have limited technical resources. If you are just starting out, it may be wise to consider focusing your development resources on the core product, and tough out some time with SaaS products, even if they aren’t quite the right fit. While internal tools are a great investment for your technical team, make sure your core product is at least in its first iteration before looking internally. 

‍

When another company has done it best. Here are some specific areas where we think SaaS products do a great job:

• Communication. There are plenty of tools out there that serve the purpose of communication and serve it well. Be it Microsoft Teams, Slack, Gmail, or others, there’s no need to reinvent the wheel here. This is also important to consider in any internal tool build - if your communication happens elsewhere, don’t try to segment certain conversations in apps that will fragment and disperse the information and only cause more confusion. 
• Ticketing. Ticketing systems like Zendesk are already built for scale and are usually optimized to cope with a huge load - something that is hard to build yourself. Additionally, engineers are often accustomed to working with the main platforms, and will thus be quicker to onboard. 
• Complex task management. Companies like Jira, Linear, Monday.com, and Trello have already designed great software that offers the level of flexibility that your teams are likely looking for when managing their tasks. Their particular strength is allowing users to take the same information and see it in all kinds of useful formats - and any manager knows it's a bad idea to force a task management system on your employees, people have their own ways!

‍

‍

So what are the pros of buying an internal tool or SaaS product?

‍

• These tools are usually the expert solution to your problem. 

• Teams of people design these tools with your business needs in mind, and are often experts in a very niche problem that you might need to solve - this is particularly useful if you are completely familiar with the area you are looking to build for. 
• You aren’t likely to build the next Zendesk, so if it solves your problem (or close enough), it might be best.

• They are ready-made, so there’s no need to hire development personnel or use up developers’ time. This can naturally save major time and money and can also empower individual teams to find their own solutions, rather than relying on your engineering teams.
• They can be used immediately and the onboarding process is usually optimized. You also won’t have to create documentation to use them. 
• They can definitely be price-effective in the short term. SaaS products will often give you a great deal to get you in the door, and will inevitably raise prices over time and as you scale. Nevertheless, if you simply use a SaaS product as a stepping stone to a custom build, they can certainly be affordable in the short term.
• Scale is built-in. SaaS products take care of security, SSO, compliance, and increased volume for you - they are ready to grow with your business (though don’t forget, as you grow, so might the price tag). 

‍

‍

What are the cons of buying an internal tool or SaaS product?

‍

• Limited customization potential. While you can typically find a tool that does the job required, it will likely be limited in nature. While you grow and your needs change, you may quickly reach the outer bounds of use for a ready-made product. Scope out what the long term should look like for this app and let that aid your decision.
• A variable SaaS fee can lead to surprises - SaaS products can quickly turn up the monthly costs whenever they like if you are locked into their platform 
• Reduced system redundancy and dependency on an external system for a (core) business function. If the product goes down and this tool is one of your critical functions - it could be bad news for your business, and you’ll have little to no control over the maintenance of the platform. 
• Difficult to integrate multiple tools. Ready-made tools are typically made to perform one job; if multiple tasks are required, multiple tools might be needed. If those tools aren’t free, the monthly costs can then add up quickly, and teams might have their tasks dispersed over multiple platforms. 
• Individual access management is now mostly in the hands of the product host. This can also be a pro; research on how security is handled is definitely necessary here. By placing business logic on an external system, it reduces the resilience and redundancy of your system.
• Startups change their needs - SaaS products can make it expensive to change small parts and once you are locked in, it’s in their interests to hold the keys. This means they are often less scalable in the long term - important, if that’s what you need.

‍

Now we’ve looked at SaaS products pros and cons, let’s take a closer look at their main rival: the custom build. 

‍

‍

When to custom build your app (from scratch, on low/no-code, or using developer tools)

Build vs buy is actually a lot less black and white than it used to be - and in this gray area we can also find a range of different tools that will help you avoid some of the cons of buying SaaS, without needing all the time and money of a traditional custom-coded app. 

‍

As building now comes in many different formats, so too do the pros and cons of each. In this article, we will look at building in general, but we go into the differences between each format in more detail in our article: How to build internal tools in 2023. 

‍

‍

‍

‍

When to build your own internal tool:

• You have outgrown your SaaS tools. If you have already reached the bounds of your SaaS tools, and are limited by what they cannot do, it’s time to look at developing your own. You may find that working with a SaaS product in the first place helps you to know exactly what you do and don’t want. 
• You know you will quickly outgrow your SaaS tools (very soon). If you can already envision a time in the near future when you will be looking for more than a SaaS product provides, or you want to grow and change the tool fast and need to avoid the hassle of migration - it might be worth putting the time straight into a custom-built tool, rather than spending time onboarding your team into a SaaS product you will soon deprecate. 
• You have tested an MVP, and you know the tool will bring value to your company. If you already know exactly what you want, and know it will bring you value - why wait? If you have done the calculations, and you are confident you will get a good ROI from a custom product, this is a great time to look at building. 
• If you have a technical team or at least some technical know-how and this tool is a priority, a custom tool will be a good investment for the long-term. If you already have these resources on board, it might be worth using them.
• This tool may become a part of your core product, and you want to maintain IP. This is most pertinent if you custom code. Having proprietary tools brings value to your product and company. 

‍

‍

What are the pros of building your own internal tools?

• More agency and control. You own your code and the product you have developed, and you have the tools to scale it, expand functionality, and fix it. 
• More control over product cost. This is a tricky one - as it’s not inherently cheaper to build your own product, but in the long term it can certainly turn out that way, if you plan it well. It’s certainly better to invest upfront cost in development (and some later maintenance) than it is to stay locked in to a costly SaaS product that is not providing its fair value in return. You are in control of these costs by building and are less likely to be caught out by sudden price hikes for an app that is critical to your operations. If you need a custom feature, you also don’t have to worry about the SaaS product charging you excessive amounts to make something custom for your organization. 
• Less lock-in. Depending on how you build, you will have less lock-in than a SaaS product - but this varies by build type. 
• Reduced bloat. While SaaS products are usually more fleshed out with all the bells and whistles, sometimes they are just a little too fleshed out. Custom building an app allows you to concentrate functionality.
• Ability to follow your company’s source control protocols. When using an internal tool SAAS product versioning, releasing changes, and permissioning is generally controlled at the product level. When creating your own tool, you can manage changes to your applications using SCM providers like GitHub and GitLab (this sadly isn’t true for many low-code no code platforms, however).
• Branding. You can often match company themes and styling with custom apps - this is possibly more of an issue for larger businesses or enterprise companies, but it can be an issue nonetheless. 
• Business IP Moat. If a SaaS product already exists for your tool, it’s a relatively low barrier to entry for competitors. Creating your own personalized internal tool that sets you two steps ahead can be the much needed moat to separate your business from the pack. When you own your tools and those aren’t public knowledge, its a lot harder for competitors to copy the way you do things. 

‍

What are the cons of building your own internal tools?

‍

• Often higher setup costs, ranging from an engineer to fully code your tool to even just having an engineer building an app on a platform, custom building will likely have some set up costs (don’t forget you will potentially have less ongoing costs however). 
• Onboarding and documentation is all on you. Depending on how complex your app is, and how you want to use it, you are in charge of organizing onboarding and making sure documentation is available and useful to your users. These additional resources will require some initial input and this will need updating. 
• Maintenance.  The degree to which you need to maintain all elements depends on the way you build, but at the end of the day, you are in charge of your own application. This can differ slightly when using a developer platform, rather than custom coding, as they will keep on top of API connections and more.
• Scale and iterations. You yourself will have to scale your app to match the scale of your company, and if you grow quickly this could mean lots of changes and maintenance to grow the app. While this is also a con of SaaS products due to their limitations, this can be a con for custom building depending on the size of your engineering team, and how much capacity they have for this particular task.
• You’re on your own! If you aren’t really sure what you need the app to look like, and how it should work, it’s difficult to start with a blank slate, and you may find yourself making major changes throughout its lifecycle (often much to the dismay of your engineers). SaaS products can serve as a basic MVP for your internal tool.

‍

If you still aren’t sure which apps are worth the investment, read our Internal Tools 101 to help you decide what to build, and how to plan and build them best. 

‍