The Internal Tooling Build vs Buy Question

What you actually need to know

• The default for internal tooling should be buy. Commercial products like Retool, Metabase, and Notion cover the majority of internal tooling needs at a cost that is lower than custom builds over three years.
• The "we need more control" argument for building rarely holds. Control is valuable only when the requirement that drives it is concrete and specific.
• Internal tools built quickly without tests, documentation, or a designated owner become maintenance liabilities that outlast their original purpose.
• The real cost of a two-day internal tool build is 5-15 days over three years when maintenance and knowledge transfer are included.
• The categories where custom internal tooling pays off are deeply domain-specific workflows that no commercial product was designed for.

The core argument

The internal tool that takes two days to build and two years to maintain is a common trap in engineering teams that are proud of their ability to build things. The tool exists because a team member said "I could build that in a day" and was right about the build but wrong about the total cost. Metabase would have been installed in two hours and maintained by the vendor. The custom dashboard requires a developer day every three months to update as the data schema changes.

This is not an argument against ever building internal tools. It is an argument that the build decision deserves the same scrutiny as the product build decision: what does commercial tool X cost over three years, what does building and maintaining the equivalent cost over three years, and does the custom build provide something the commercial tool cannot?

The teams that consistently over-build internal tooling have a cultural dynamic that treats commercial software as a sign of engineering inadequacy. "We could build a better version of that" is sometimes true -- and almost never relevant, because the relevant question is "does the commercial version meet the requirements for three years at a cost that is less than a custom build?" The answer is usually yes.

The categories where commercial wins

Admin panels and back-office tools. The internal tool that allows customer support to view customer data, make account adjustments, and process refunds is an admin panel. Retool, AppSmith, and Forest Admin build these in hours with a visual builder that connects to the existing database. A custom-built admin panel that does the same thing costs 2-4 weeks of development and requires ongoing maintenance as the data schema evolves. The commercial option is faster, cheaper, and does not require engineering capacity to maintain.

Reporting and analytics dashboards. Metabase and Redash connect to any SQL database and allow non-technical team members to build and explore dashboards without writing SQL. The custom-built reporting dashboard requires a developer to add new metrics as business questions evolve. The commercial option is self-serve, which is its primary advantage: the person who wants the answer can get it without waiting for developer capacity.

Customer support tooling. Intercom, Help Scout, and Crisp provide customer support interfaces, email and chat integration, ticket management, and reporting. Building equivalent functionality is a significant project. The commercial options are also where customer support best practices are implemented -- the custom build starts from scratch on the practices that vendors have spent years refining.

The categories where custom wins

Domain-specific operational workflows. A fintech company's loan origination workflow has specific steps, compliance requirements, and data fields that no commercial product was designed for. A healthcare company's patient intake process has regulatory requirements that generic form builders do not handle. A manufacturing company's production planning interface integrates with machinery data that no commercial product connects to natively. In these cases, the domain specificity makes commercial products inadequate and custom builds necessary.

Deep internal system integration. An internal tool that must integrate bidirectionally with a proprietary legacy system that has no APIs may require custom development regardless of what commercial tool is chosen. If the integration cost of a commercial tool approaches the build cost of a custom tool that integrates natively, the custom build may be justified.

Competitive differentiation in operations. Occasionally, an internal tool is the source of a genuine operational advantage -- the custom pricing calculator that allows the sales team to generate quotes that competitors cannot match in speed or accuracy, the custom routing tool that optimizes delivery in a way that commercial tools do not support. In these cases, the internal tool is worth building because it provides competitive value, not just operational value.

The low-code platform question

Retool, AppSmith, Bubble, and similar low-code platforms offer a middle path between buying a commercial product and building from scratch. The value: much faster initial development than a custom build, enough flexibility to handle domain-specific requirements that off-the-shelf products cannot.

The risks: platform dependency (if the platform changes pricing or terms, migrating away is difficult), performance limitations for complex tools, and the eventual ceiling where the platform's flexibility is not sufficient for the requirement.

My evaluation of low-code platforms: excellent for admin panels, internal CRUD tools, and dashboards that connect to existing data sources. Not appropriate for tools that require complex business logic, custom data processing, or performance-critical interfaces. The platform dependency risk is real and should be factored into the total cost comparison.

The maintenance problem

The maintenance problem with internal tools built quickly is not the code quality -- it is the absence of a designated owner. A tool built by an engineer who has since moved to a different team has no one who knows it well enough to fix it quickly when it breaks. A tool built without tests cannot be confidently modified when the underlying data schema changes. A tool built without documentation requires reading the code to understand why specific decisions were made.

These problems compound over time. The tool that is maintained by "whoever can fix it when it breaks" is the tool that breaks at the worst possible time -- when the team is at capacity and the original author is no longer available.

The solution is not to avoid building internal tools. It is to treat internal tools as production software with the same ownership, documentation, and testing requirements as customer-facing features. This requires the same time investment as building the tool, which makes the build-vs-buy calculation more accurate: the tool that takes two days to build and one day to document and test costs three days, not two.

Common mistakes teams make with internal tooling

1. Building internal tools to demonstrate engineering capability rather than to solve a specific problem. "We built that in Retool but we could build it better ourselves" is a build justification that the business did not ask for.
2. Not designating an owner for each internal tool. A tool without an owner will break and not be fixed for weeks because no one feels responsible for it.
3. Not accounting for the maintenance cost in the build-vs-buy comparison. A two-day build vs. a $50/month commercial subscription looks clearly in favor of the build. A two-day build plus $1,000/year in maintenance vs. $600/year for the commercial subscription looks different.
4. Building internal tools that are critical to business operations without backup access if the original developer is unavailable. If the tool breaks and only one person knows how to fix it, the business is dependent on that person's availability.
5. Not reassessing internal tools periodically. A tool built when no commercial option existed may now have a commercial equivalent that is better and cheaper to maintain. Annual review of internal tools against the current commercial landscape is worth the time.

Where to start: a 3-step internal tooling audit

Step 1: List every internal tool the team uses and identify who the owner is. Tools without a designated owner are the highest-risk tools -- they will break and no one will know how to fix them.

Step 2: For each custom-built tool, evaluate whether a commercial equivalent now exists. The commercial tooling landscape changes quickly. A tool that was built two years ago because no commercial option existed may have a commercial equivalent today that is cheaper to maintain.

Step 3: For any new internal tool request, run the three-year cost comparison before deciding to build. Include the build time, the annual maintenance estimate (20 percent of build time per year), and the commercial option's subscription cost. Make the decision with both numbers visible.

The Tool That Serves the Business

Yashveer Singh. Founder of Yashveer Labs. The internal tooling decisions I have seen go best are the ones where the team asked "what does this need to do?" before asking "should we build it?" The admin panel that needed to let support view customer data and process refunds was built in Retool in three hours. The custom loan workflow tool that needed to enforce a specific compliance process was built custom in three weeks. Both decisions were correct because the question was asked before the answer was assumed.

Related reading

• The Internal CRM Build: When It Pays Off
• The Internal Tooling Roadmap: Why It Matters as Much as the Product Roadmap
• The Hidden Cost of Free Tools: Vendor Lock-In Math
• The Finance Stack for a SaaS Business