Internal Tools: Build, Buy, or Automate? A Founder's Decision Guide
Internal tools are the software your own team uses to run the company: admin panels, dashboards, customer-lookup screens, the ops console someone hacked together in a spreadsheet. This guide is informational. If you searched "internal tools" because your team keeps asking for one more app and you're trying to figure out whether to build it, buy it, or do something else entirely, you're in the right place. We'll give you a decision framework, not a sales pitch for any one platform.
Here's the trap most internal tooling advice walks you into. It assumes a binary: either you buy a Retool-style internal tools builder and pay per seat, or you hire engineers to build internal apps from scratch. For a $2-10M company, that binary quietly costs you the thing you have least of, which is your founder's hours. The real answer has three doors, not two. Buy commodity software. Build only the rare wedge that is genuinely your edge. And automate the glue in between on the accounts you already own, instead of building or buying an app at all.
That third door is the one nobody sells you, because there's no per-seat license to sell. So let's talk about it honestly.
Why "build vs buy" is the wrong first question
Walk into most internal tools conversations and the framing is already broken. People argue build versus buy as if those are the only two options, then spend a quarter debating which custom app builder to standardize on. Meanwhile the actual problem on the ground is rarely "we need an app." It's "the data in our CRM never makes it into billing without someone copying it by hand."
The numbers back this up. Developers spend roughly a third of their time building and maintaining internal tools like admin panels and dashboards, according to Retool's State of Internal Tools research, and around 86% of survey respondents said their organization spent as much or more time on internal tools than the year before. That's a lot of expensive engineering hours going toward software your customers will never see. At a 20-to-50-person company, those are the same engineers you hired to build the product. Every hour they spend on an internal admin panel is an hour they're not spending on the thing you actually sell.
Across the scaling companies we've worked with, the founder bottleneck is almost always the same shape. It isn't a missing application. It's a chain of manual handoffs between tools you already pay for, and the founder is the human glue holding the chain together. You don't need to build software to fix that. You need your tools to talk to each other.
The three doors: buy, build, automate
Think of every internal tooling request as falling into one of three buckets. Most teams force everything into the first two and ignore the third.
Buy vs Build vs Automate: A Side-by-Side Comparison
| Approach | Best for | What it costs you | What you own |
|---|---|---|---|
| Buy commodity SaaS | CRM, accounting, support desk, payroll, anything thousands of companies need identically | A subscription, plus onboarding time | A login, not the system |
| Build a custom app | The rare wedge: a workflow that is genuinely your competitive edge | Engineering hours now and forever (maintenance never ends) | The code, and the obligation to maintain it |
| Automate the glue | The handoffs and data movement between tools you already own | A fraction of one engineer, often a fractional partner | Your own accounts and scenarios, cancel anytime |
The mistake isn't picking the wrong door for a given problem. It's not realizing the third door exists. A customer-lookup tool, a daily revenue dashboard, an onboarding checklist that pings three systems: none of those are products you should build, and none are products you should go shopping for. They're glue. Glue gets automated.
Buy the commodity. Build the wedge, and only the wedge. Automate everything in between.
What actually deserves a custom build
Custom build is not the enemy. Building the wrong thing is. The question to ask before greenlighting any internal app is brutally simple: would a competitor copying this give them an edge over us?
If the answer is no, you're looking at commodity or glue, and building it is a tax you'll pay forever. McKinsey estimates that current generative AI and other technologies have the potential to automate work activities that absorb 60 to 70 percent of employees' time today. A huge share of what feels like "we need to build a tool for this" is really just repetitive activity waiting to be automated, not a software gap waiting for a custom app.
If the answer is yes, that's your wedge, and that's worth building well. Even then, "build" doesn't have to mean "hire a full-time engineer and own a codebase for the next decade." That's where the in-house versus outsourced question gets interesting, and where a fractional build-partner changes the math.
The real cost comparison nobody runs
Here's the part founders skip. They compare the sticker price of a tool against the sticker price of an engineer's salary and stop there. That's the wrong comparison.
A full-time software developer costs more than the base salary suggests. The national median wage for software developers is about $132,684 a year, or roughly $65 an hour, according to BLS data, and that's before benefits, equipment, and management overhead. Hire one to own internal tools and you've added a permanent six-figure line item to maintain software that doesn't earn revenue.
Buying isn't free either. Internal tools builders charge per builder and per internal user. Retool's Team plan runs about $10 per builder and $5 per internal user per month billed annually, and its Business plan about $50 per builder and $15 per internal user. That's reasonable for one team. It compounds awkwardly when every department wants its own apps and the seat count climbs.
The automate-the-glue path tends to be the cheapest by a wide margin, because you're not buying seats for an app or paying salary for a maintainer. You're paying for the connective work once and a small monitoring cost after. In Zapier's no-code report, the top reasons businesses kept investing in no-code tools were time savings (83%), automation (76%), and flexibility (74%), and more than a third of users said the tools saved them 10 to 20 hours of work, with 10% reporting savings of at least a full 40-hour week.
How to decide in 5 steps
Run any internal tools request through this sequence before you spend a dollar or an engineering hour.
- Write down the actual outcome the team wants, in one sentence, in plain language. Not "we need a dashboard," but "the founder wants to stop manually pulling weekly revenue from three tools."
- Ask whether thousands of other companies need this identically. If yes, it's commodity, so buy it and move on.
- Ask whether a competitor copying it would gain an edge. If yes, it's your wedge, so plan to build it (and read the section on doing that without an agency contract).
- If it's neither commodity nor wedge, it's glue. Map which accounts already hold the data and where the manual handoff happens.
- Automate the handoff on your own accounts, staging-first, and assign someone to monitor it so a silent failure doesn't go unnoticed for a week.
Most requests die at step four, in the best way. They turn out to be glue, and glue never needed an app.
Readiness Checklist: before you build or buy anything
Run through this before greenlighting any internal tool. If you can't check most of these, you're not ready to commit budget yet.
- You've written the desired outcome as a single plain-language sentence.
- You've confirmed whether the function is commodity, wedge, or glue.
- You know which existing accounts already hold the data involved.
- You've estimated the ongoing maintenance cost, not just the build cost.
- You've decided who monitors the tool when it breaks (because it will).
- You've checked whether an automation between existing tools solves it without a new app.
A tool recommendation, depending on which door you pick
If you land on automate, we recommend starting with Make or Zapier for most SaaS-to-SaaS glue, and n8n when you want self-hosted control or more complex branching logic. Make is best for visual, multi-step workflows with lots of conditional logic. Zapier is best for fast, simple connections across a huge catalog of apps. If you genuinely land on buy-and-build-light, Airtable is best for teams that want a structured database with a friendly interface, and Retool is best when you truly need a custom internal app UI on top of your own data. Pick the tool to fit the door you chose, not the other way around. For a deeper purchase-decision comparison of these platforms, see our guide to workflow automation software, buy vs build.
Related guides
This pillar is the map. These guides go deeper on each fork in the road:
- The framework itself, applied to any software decision: build vs buy software.
- When the wedge really does need code: custom software development without the agency overhead.
- The buy-or-build call on automation platforms specifically: workflow automation software, buy vs build.
- Who should actually do the work: in-house vs outsourced development.
- Getting your team to actually use the tools once they exist: ai enablement for small teams.
If your bottleneck is a broader operational process rather than a single tool, our business process automation pillar covers the wider picture.
Frequently asked questions
Isn't automating the glue just a cheaper, flimsier version of building a real tool?
No, it's a different category. A custom internal tool is a standalone app with its own UI, hosting, and maintenance burden. Automating the glue means connecting the tools you already pay for so data moves between them without a human in the middle. For handoffs and data movement, the automation is the right tool, not a downgrade. You only need a custom app when the workflow itself is your competitive edge.
We already pay for a Retool-style internal tools builder. Did we waste money?
Not necessarily. A custom app builder earns its keep when you have genuine custom-UI needs on top of your own data. The waste happens when teams reach for it reflexively for problems that were really glue, paying per builder and per internal user to rebuild handoffs an automation could have solved for far less. Audit what you've built in it and ask which apps are wedges and which are glue wearing an app costume.
How do I know if a workflow is "the wedge" worth building?
Ask whether a competitor copying it would gain an edge over you. If copying it helps them, it's differentiating and worth building well. If copying it would be meaningless because everyone does it the same way, it's commodity or glue, and building custom software for it is a cost you'll carry forever for no advantage.
Do This Next
Start by listing every internal tool request your team has made in the last quarter and sorting each one into commodity, wedge, or glue. Pick the single most painful glue problem, the manual handoff that eats the most of your week, and write down the desired outcome in one plain sentence. Choose Make, Zapier, or n8n and map which accounts already hold the data before you build anything. Keep the build staging-first so nothing touches production until you approve it, and set someone to monitor it so a silent failure never costs you a week. Book time with your ops partner, or Daily Automations as your fractional automation team, if you'd rather have the glue built and monitored on your own accounts than add it to your engineers' backlog.