🛠️ Should your team build its own tools?

When do you build tools vs. buy them? In a recent meeting, someone proposed replacing Jira with a tool they had built with AI, to address some friction points we have with Jira. An experienced member of the team objected with the following points:

• Building our own tools that we can buy is a distraction from the team’s core purpose.
• What happens when the person who built the custom tool leaves? What happens when it breaks? Who fixes it?
• The issues we are having with Jira are minor compared to other challenges the team is facing that are more cultural.

These are valid points, and there are trade-offs. My colleague may be right that the tool is not the issue here in this case. My concern is the general policy of never building custom tools. A few additional points to consider:

• We don’t avoid building tools because they might not be maintained when the author leaves; rather, we build tools that anyone can maintain. The same rigor that goes into the software for the product we’re building also goes into our tools so that anyone can maintain them. Note: this is not hard; it just requires some discipline. Discipline is rare, though; a team without it is likely better off buying.
• We will build tools; that is simply part of building complex systems and world-class teams today. The open question is where to draw the line.
• LLMs have drastically lowered the cost of building AND maintaining software, including tools. We are at the point where, with the right infrastructure and tools, anyone can make improvements to a tool with an LLM if they have a clear idea of what they want. Coding and maintaining used to be the scarce resource when building stuff. With LLMs, coding and maintenance are much less scarce, and vision is becoming the valuable part.
• Tools we buy are not always a clear-cut win. They often are clunky, bloated, slow, difficult to configure, and have usability issues that the vendor does not fix. There is a maintenance cost to building your own tools, but there is also a user cost to buying one-size-fits-all tools.
• People use tools they like and that help them do their job. This is the reason bureaucratic tools, designed primarily from the perspective of management, face an uphill battle. Tools that people are forced to use rarely fulfill their potential.
• People made the same argument against open-source software (OSS) in previous decades. Who will maintain it? Is it secure and safe? Who fixes it when it breaks? Part of the value of OSS is that you do have some control. You can improve it, fix it, and influence its direction. While one of the historical benefits of OSS is that the community supplied the labor to do a lot of the work, LLMs can now fill that role in some cases.
• Progressive companies (Google, 3M, etc.) have encouraged employees to spend a percentage of their time on side projects. Many of these side projects, like the Post-it Note, have turned into revenue-producing products. Granted, these side projects were often products, but I think the concept still applies. Innovation often comes from scratching your own itch — seeing a problem and trying to solve it.

So instead of a blanket ban on internal tool building or the uncontrolled chaos of everybody vibe-coding tools ad hoc, consider the following:

1. If we are building a tool, are the deficiencies of the current solution and the things we will solve with a custom tool clearly documented? Telling someone in a meeting or making assumptions does not count.
2. Are we reusing what already exists, such as open-source projects or commercial services we can build on and extend? Building well means reusing what already exists when possible.
3. How is the tool built? Is it created from a prompt that vanishes into the ether, or is it built with proper software development rigor: start with docs, proper plans that are recorded, workflow, CI/CD, tests, automated release, and everything in Git. A practical model for software development is simply to replicate the OSS workflows internally. This allows anyone to understand and contribute to a project with low friction.
4. Is the technology selected to build tools consistent with what the company is already using, developing, and has the capability to maintain? Are we using technology components that will be maintained in the future (be careful with npm dependencies, which often have a very short half-life)? Is it biased toward simplicity, small scale, and maintainability? For instance, we probably don’t need Kubernetes, Postgres, or even Docker to deploy an internal app; Ansible and SQLite will work just fine. We probably don’t need the complexity of Rust if Go will do. If simple web page templates are adequate, we don’t need the complexity of React or other SPA technology. You can argue: who cares if an AI can do everything? But even with AI there is a cost, and this cost is usually incurred down the road. Dependencies can drag your project down with technical debt, or transparently improve it. Choose wisely as you would in the product you are building.

Enthusiasm and self-motivation are precious, rare things. Don’t squash them. Instead, give people some freedom (say, X% of their time to work on side projects), and direct them into a process where side projects are built with the same rigor as the official projects. If you don’t give motivated people an official path, they will probably do something unofficial anyway. Experiments or prototypes are throwaway work and a completely different thing — that is not what we are talking about here.

As an example, I built my own custom meeting app to solve problems I kept running into with Zoom meetings, including:

• Sitting in a meeting, waiting for the owner to show up so we can get started.
• Doing the dance where someone else needs to host the meeting because the host is going on vacation, the calendar invite does not get updated, and some people forget about the change.
• People struggling to get into a meeting because they don’t have the credentials.
• Clunky Zoom add-ons for recording meeting transcripts that occasionally don’t work.

This custom application solves my needs very well and is super easy to maintain. This is partly due to how I build it: I choose technologies that are simple to use and deploy, like Go, and leverage GitHub and CI/CD workflows. I also bought the core Jitsi service, which illustrates that build vs. buy is a continuum, not an absolute. Most developers could easily pick up maintenance on this tool — I invite you to try it! This is the pattern I aim for with any small custom tool.

Products today are more than just code, drawings, models, and BOMs; they also include the PROCESS used to build AND maintain them. The PROCESS is increasingly becoming the secret sauce, not the design assets themselves, because now anyone can reverse engineer your product. The PROCESS is what allows you to move faster and work more efficiently than anyone else. Tools that encode your PROCESS are hard to copy.

When to build? When to buy? The question of build vs. buy is perhaps less of an issue than how you build your internal tools. If you answer the latter question, the former will probably take care of itself. Tools people use shape culture, and a team that builds its own tools with discipline is building that culture.