3 experts on building vs. buying internal tools (and why the question is a false dichotomy)

Don’t underestimate the potential impact of internal tools. According to The State of Internal Tools 2021, one in three employees (at companies of more than 10 employees) are using internal apps that a developer built.

That potential makes the build vs. buy question hairier: How best can you allocate your developer’s time?

We turned to three experts, each from software companies focused on technical audiences, to learn how they thought through the build vs. buy question.

The top-line answer that emerged was this: Build vs. buy is a false dichotomy. Our experts reveal that, especially with low-code platforms, your internal tool development should be context-dependent and should, at different times, include built and bought components.

Halp: Build using building blocks you buy

Andrew Homeyer, former CTO of Halp, recommends buying no-code platforms that enable you to build internal tools.

“Technically we’re building,” Homeyer says, when asking about building vs. buying, “but we’re using building blocks that are no code.” With no-code platforms, Halp developers can, according to Homeyer, “hack together” solutions that, while “brittle,” work. And building something that works fast is a priority for Halp.

Speed, as any project manager knows, doesn’t involve throwing more developers at a problem. Instead, with no-code platforms, Halp can decouple engineering effort from results. “It’s pretty amazing,” Homeyer says, “that all the developer has to do is say ‘cool, track this event.’ And then it gets sent to the right places.” With no-code platforms, building is often as simple as commanding. Say what you need done and it will get done.

How do we enable sales and marketing to have what they need just to go get shit done?

One of Halp’s goals when it comes to building internal tools is to enable non-technical employees to modify internal tools. Halp is Software as a Service (SaaS) heavy, using products like Segment, Workato, Salesforce, and Autopilot to create a smooth customer adoption flow. But that flow will only remain smooth if the employees closest to customers can iterate it. That’s why, with low code platforms, Halp ensures the “process can be tweaked and modified by a salesperson, or someone in marketing.”

The ruling question, according to Homeyer, is: “How do we enable sales and marketing to have what they need just to go get shit done?” That’s the goal of their internal tool program, and Halp has found success building internal tools with vendor software.

As a result of this internal tool program, Halp has built a variety of important internal tools. Their systems for data management are worth highlighting, specifically an internal tool that aids with billing structure.

Halp uses Stripe for subscriptions, but according to Homeyer, “there’s always something a little bit off.” One customer might need a specific discount, one might need a trial extended, one might have experienced something weird with their subscription renewal. The problem is that some of these issues can’t be solved, at least not easily, within Stripe itself. Often, Halp’s developers need to go into their actual database. But that’s not ideal.

“Even opening a ticket and having an engineer touch the database—we don’t love doing that,” says Homeyer. “Anytime you’re touching data, something is usually going to break down the road.”

The key for Halp was building a lightweight system that makes it easy for team members to make changes. If they need to enter a coupon code, for example, all that involves now is filling out a text field. “This took five minutes and now it works, and [we] don’t have to think about it again.”

On Deck: Build first, then buy

Curtis Cummings, a senior software engineer at On Deck, recommends building before buying.

“On Deck does something a little different than I’ve seen at most other startups,” Cummings acknowledges. Before creating a custom solution, they build a low-code minimum viable product (MVP). Why? According to Cummings, “the scrappy MVP gets you 70% or 80% of the way there.” Plus, that 70% or 80% of progress delivers irreplaceable insights.

Along the way, you gain “user data to actually back up and validate why you built it and things that you might want to improve.” Only from that point, armed with an MVP and validation, will On Deck even consider completing the remaining 20% and building a custom tool.

You have to evaluate on a case-by-case basis.

Cummings is risk-averse when it comes to building internal tools. The last thing he wants, he says, is to have “built something nobody wanted.” Cummings draws on a career in consulting—with the scars to prove it.

During his consulting career, there were numerous instances where “we had this perfect spec, we built it perfectly to spec, went out to users and it fell flat on its face because all the assumptions that backed up that spec weren’t validated or grounded in user data.”

By buying a no-code platform and building MVPs with it, On Deck can validate the idea before putting, says Cummings, a “bunch of engineering resources onto it.”

The process of evaluation is a careful one. Engineering resources are costly, and their investment has to be carefully justified. Cummings warns against generalization: “You have to evaluate on a case-by-case basis.”

The result of this calculation has involved both custom solutions and low-code solutions. In terms of low code, On Deck’s primary platforms have been Zapier, Airtable, and Retool. Automation has been a prime use case, but On Deck has also built tooling for operations teams that help them manage different facets of their programs, like member management. With Retool, they’ve even built a lightweight content management system (CMS) they use to send weekly updates to fellows.

Auth0: Build MVPs if you don’t have budget, but buy as your company grows

Sole Pano, a product manager working at Auth0 in the service management and administration experience team, says that the build vs. buy question depends on the stage of your company’s growth.

According to Pano, early-stage companies tend to have less budget and fewer requirements. “Maybe you just need to send the customer a notification,” Pano says, as an example. “You don’t need to scale because you don’t have a lot of customers. And so you just do it, and you build it yourself and it’s easy, fast, whatever.” When the budget is small and the requirements are few, it might just be better to build a super scrappy MVP to keep moving forward. But don’t expect that to last long.

Your solution that worked today stops working at some point.

As your company grows, however, you likely have more requirements, which may require special tools. Auth0, which is in the identity and authentication space, is deeply familiar with how complex requirements can get. Pano cites security and compliance as top concerns. But beyond that, “There are many more customers you need to consider, more volume.”

When the volume of customers rises, “your solution that worked stops working at some points,” says Pano. Then, she says, you’re stuck with a question: “Should I refactor and rebuild everything or just pay?”

The build vs. buy question shifts as your company grows. You have more customers and more requirements, but you also have more money. You can afford, according to Pano, “to buy these other products that will do it 10 or 100 times better than us.”

Unless you need something very specific, Pano says, you’re eventually better off buying instead of building. With this perspective in mind, Auth0 has built and bought a variety of tools that range from automation to visibility.

Auth0 has built automation tools related to customer subscription management and integrations with systems like Stripe and Salesforce. Internal tools also help them manage customer environments, including provisioning and containment management. Workflow has been a key target, especially with regard to helping their customer success teams onboard enterprise clients.

Visibility has been another goal. For example, Pano cites, the support team at one point requested help assisting customers with ticketing. Auth0 built an internal to help that was secure and compliant (there are those requirements again). With the right internal tool, the customer success team could see the configuration of a customer’s environment and provide the precise help they needed.

Build or buy: A combination, not a dichotomy

Our experts show that the build vs. buy question is a false dichotomy.

Auth0 says the answer changes during company growth; On Deck says the answer changes depending on the results of an MVP; Halp says the answer is both—buy no-code tools and use them to build internal tools.

Your answer to the question will be just as dependent on your own context. How big is your company? Do you need to build an MVP? How many and how often do you need to build internal tools? The answers to these questions and more can help guide your internal tool decisions.