Building Internal Tools: Better Than Buying?

To buy or to build: That is the question, and it’s a hefty one.

The first variables that come up during the building-versus-buying internal tools discussion are development costs and ramp-up time. A knee-jerk reaction is often to surmise that if an organization can afford both the money and the time to build an internal tool from scratch, they should do so, otherwise they should purchase a third-party solution.

Unfortunately, this assessment omits the most important variable: Functionality.

Even across five-star software reviews, the number one downside for users is lack of specific functionalities and capabilities: “I only wish it could do X…”

Sound familiar? Internal tools’ functionality is a huge point of contention because it’s nearly impossible for third-party internal software to correctly solve for every business need that their customers may have.

Of course, there are many workflows that are straightforward and common across companies. Take a basic sales process where you’re managing a deal from lead to opportunity to closed won —the choice to buy a CRM (rather than build one from scratch) is a no-brainer. The same goes for expense management: Very unlikely you’re going to build one yourself as the process to submit and reimburse for expenses is pretty standard.

But what about all those other internal tools that are unique to your business as your product? 

Skip ahead:

A good internal tool gives stakeholders:

A solution that is quickly deployable

The development of internal software only takes place after a business need has been clearly identified. Say for instance, a company is facing an acquisition and will need a new way to visually interact with data from a SQL database and a MongoDB database. This need will likely be addressed and specs for an internal solution will be outlined concurrently with the company’s acquisition roadmap.

Software to meet current and future needs

Internal tools, specifically ones that support critical business needs, aren’t often plug-and-play solutions. Where outward-facing services like Mailchimp usually offer a good and accurate feature package for their users, internal software providers can only speculate.

When the buying versus building discussion is at hand, businesses will consider not only their current needs, but any future needs that may arise. With third-party software, the development plan is contingent on its existing software features. With internally-built software, the features are mostly weighed against their development costs.

Ease-of-use and efficiency

Stakeholders are ultimately interested in something that saves time and development resources in the long run. Whatever solution is decided upon needs to be easy to use—for everyone using it and not just developers and technical people. This is often a critical balancing point for software that is built and developed internally.

Something that won’t deplete development resources

Software development—whether internal or external—has a cost, and predicting these costs upfront is the first step in making a decision about whether or not building an internal tool is a viable solution.

Typical development resources required to build software are more than just wages, and include:

  • People: Finding the right roles, paying them, keeping them happy and productive
  • Equipment and tools, the software your team will use
  • Overhead expenses, like an office, security infrastructure, contractors, etc.

It’s important to nail these down ahead of time, as close to an actual dollar amount as possible, in order to truly make an informed decision.

Furthermore, opportunity costs must also be considered. As in, what else could be afforded with the total development costs? Is the solution in mind truly the best possible expenditure?

Is what you're building a core competency of your business? If the answer is yes - build it yourself. If the answer is no, buy pre-made software or even outsource the work.

- Adam Spector, Co-founder of Abstract Ops

Purchasing a viable solution

Most businesses already use third-party internal tools, as many options are pre-made to fit a well-known business niche. A few examples:

  • CRMs are used to manage contacts, standardize (and send) outreach, and allow collaboration between salespeople.
  • Project management tools like Monday create smart dashboards and admin panels for project managers and stakeholders to centralize their efforts.
  • A CMS lets content production teams control every aspect of their content and the way it is interacted with online.
  • Helpdesk software serves as a go-between for customer support reps and customers, both as a portal to divert users towards resources, and as a method of direct communication.
  • Ticketing tools turn projects into bite-sized, collaborative tasks to be completed during sprints.
  • HR software manages information and workflows in a centralized location.
There is always less friction to start using [third-party] tools and show value than to argue for budget upfront, [but there is wisdom in] understanding the downsides of such hacked-together solutions.

Sean Sullivan, Product Management Consultant at Product Stride

👉 Remember: A good internal tool is any software or app that saves the company time, money, and resources.

Slack’s guide to building internal tools

Informed by Sean Herron, Business Technology Head of Applications Engineering, Slack:

Slack tried a bunch of different things before coming up with its development approach. Dubbed “Slack on Slack,” it’s an approach that aims to keep the Slack platform at the core of all new development.

The objective of Slack on Slack is to use the platform’s capabilities to create a simple, pleasant, and productive experience for Slack’s own employees—using their own built-in APIs and features. Because at the end of the day, Slack is the only common tool that every Slack employee uses.

The business technology approached the Slack on Slack project with the belief that there are four main areas of focus within business technology:

  • Employee services: Ensuring employees have the productivity essentials they need to do their jobs
  • Enterprise architecture: Planning systems and services to be interoperable and scalable
  • Business systems: The systems that keep the platform running
  • Data and analytics: Ensuring that employees have high-quality and accessible data

The approach

Sean Herron’s approach to prioritization is rooted in three fundamental questions:

  1. Business impact: Does this solve a significant issue—and for what population of users?
  2. Slack as an amplifier: Does integrating with Slack (the Slack on Slack approach) make the process better for the end user?
  3. Improving the tech ecosystem: Is this internal tool helpful for the team who is building the company?

Further, there are three different categories of internal applications that serve vastly different teams:

External apps: Off the shelf, ready to use for a specific purpose. Known quantities, you typically know that these apps have gone through a review process.

Workflow builders: These are no-code ways to automate routine tasks. Slack builds these directly into their platform so that it’s easy to get started, or build custom tools on top of them.

Custom applications: From simple notifications all the way to powerful systems that integrate with multiple tools. These are built internally by developers.

The process

Mapping out business needs is always a chaotic process, and Slack was no exception. What ultimately worked was recording each business need, regardless of scope or niche, weighing them based on structured critera, and prioritizing them based on their impact.

It’s not always that straightforward. The approach that the Business Technology team used was to first map out their business needs with their own team before soliciting the input of other teams and business partners, like sales and marketing.

This second step—getting opinions and insights from other teams—is not to be taken lightly. Sean Herron opines that the correct way to complete this step is to spend a considerable amount of time and energy to get a very clear understanding of these teams’ problems, literally sitting next to the stakeholders (or on a screenshare) and working through their workflows and use cases.

👉 Remember: A successful rollout requires you to think about adoption at every stage of the development cycle.

The last team to weigh in is the employee base, AKA the rest of the company. In Slack’s case, as a considerably sizeable organization, the employee base serves as a good (albeit broad) source of unique information and creative, innovative ideas. The downside is that they may not always be pertinent, and might even feel like random feature requests.

The results

Informed by Monica Wilkinson, Business Technology Staff Application Engineer, Slack:

Using the approach and process outlined above, Monica’s team created a custom-developed internal tool for the sales team affectionately named ApprovalsBot. In discussions with the stakeholders (the sales team), the following questions were identified:

  • How can the Business technology team help streamline the deal approval process?
  • Is there any way to empower managers to approve deals quickly, with all the right information at their fingertips?
  • How can the right people be kept in the loop during the deal approval process?

And thus, the Business Technology team invented ApprovalsBot and brought it through the internal tools development process. Now completed, the ApprovalsBot internal application exists as an integration between Slack and Salesforce.

When salespeople run ApprovalsBot (by clicking a button in Salesforce), a message is sent to all related persons in Slack. The sales reps also get a custom modal in their Slack side panel displaying all pertinent information to the specific deal.

The main measures of success for this custom-built tool are:

Productivity: ApprovalsBot helps the sales team socialize and get approval for special deal terms for their prospective customers. This saves them countless hours of repetitive work.

System of Record: Connecting to the Salesforce Deals engine provides a true system of record for auditing and reporting.

In conclusion: Buying versus building

Obviously there’s no one-size-fits-all solution, but we can help you do the math. Companies are different, their internal needs are different, their capacity for internal development is different, and so on, but a couple of things stay the same.

Purchasing an internal tool

The biggest upside to purchasing an internal tool is that it doesn’t drain the company’s development resources—it just drains the cash. Buying a third-party solution is almost always the most cost-effective option, but the costs that are saved upfront might prove costly later on.

It’s important to keep in mind that out-of-the-box internal tools are created for a specific usage, but any business needs beyond this scope might not get met, and may require development resources anyway. For tools that serve general and predictable needs, however, like CRMs or project management software, there usually won’t be any problems.

But if your internal software needs are unique to your business—like tools that support your product or read/write to databases and APIs—a third-party solution just won’t cut it.

Developing an internal tool

Converse to purchasing an internal tool, building one yourself is usually the more expensive route, but you always end up with a perfectly-tailored technical solution that solves your business needs. Especially with a healthy and realistic development approach, building your internal tools ensures you end up with the exact features and functionality your business requires.

The downside is that developing your own tools in-house is:

  • Financially costly
  • Time-consuming
  • A drain on development resources

The third option (our favorite)

Surprise. It’s us. 🎉

For internal tools that are as unique to your business as your product, we’ve got you covered. You might think that in-house development is the only choice you have, but that’s not the case at all. 

Internal is an internal tools platform for building custom business applications and workflows on top of virtually any database or API, with an easy drag-and-drop interface.

The secret sauce is Internal’s powerful app builder that’s easy for anyone to use (whether they know code or not), robust developer tools that allow users to write their own custom code (if they choose to), and super granular permissions that allow admins to control who has read/write privileges at the attribute and parameter level.

These factors combined give teams a fast and easy way to build perfectly-tailored internal tools for their company—without the months of development work and costs associated with developing your internal tools from scratch.

A gif of the Internal.io App Builder in action

For those who truly love a no-code developer experience, Internal also has a large selection of pre-made functions that are automatically generated upon being connected to a database.

So if you're curious, you might consider creating a free account, or scheduling a demo to talk to the pros about your specific application. Happy building!

Get started now.

Oops! Something went wrong while submitting the form.

Check your email. We sent a verification link to your email.

New verification link sent.

Send a new link

Good news! Your company already has an Internal account. Do you want to request access?

You'll get an invite to Internal once your company admin approves your request.

Request Access