Every small agency and development team has a graveyard of internal tools. The monitoring dashboard someone built over a weekend. The deployment script that only one person understood. The Slack bot that worked for three months before an API change broke it and nobody noticed for two more.
We have our own graveyard. Building tools is the easy part. Building tools that people actually use — and that stay useful — is a different problem entirely.
The Internal Tool Graveyard
Internal tools typically die for one of three reasons.
Nobody asked for them. Someone sees a problem, builds a solution in isolation, and launches it to a team that was already coping fine with their existing workflow. The tool solves a problem that wasn’t painful enough to justify the context switch of adopting something new.
They try to do too much. What starts as a simple status page becomes a dashboard, then a reporting tool, then a project management system. Each feature adds complexity. Complexity adds maintenance burden. Eventually the tool becomes harder to use than the manual process it replaced.
Nobody owns them. The person who built the tool moves on to client work. Dependencies fall behind. A service it connects to changes its API. Small bugs accumulate. One morning the tool is broken and nobody fixes it because nobody considers it their responsibility.
We’ve seen all three patterns in our own team. The solution isn’t to stop building tools — it’s to build them differently.
Three Rules for Tools That Survive
After several rounds of retrospectives discussing which internal tools were working and which had become noise, we settled on three principles that determine whether a tool is worth building and maintaining.
1. It Must Solve a Real, Recurring Pain
The bar is simple: is someone on the team doing this manually, repeatedly, and is it costing meaningful time? If you’re spending two hours a week on a task that a tool could eliminate, the maths works out within a quarter. If you’re solving a problem that happens once a month and takes ten minutes, leave it manual.
This sounds obvious, but it eliminates most tool ideas at the proposal stage. “It would be cool to have” is not the same as “we need this.” Cool-to-have tools are the ones that end up in the graveyard.
2. Build It With Your Existing Stack
If your team writes Ruby, build the tool in Ruby. If you’re a Node.js shop, use Node.js. The moment you introduce a language or framework that only one person knows, you’ve created a single point of failure for maintenance.
This applies to infrastructure too. If you’re already running containers, containerise the tool. If you’re deploying to your existing hosting platform, put the tool there too. Every unfamiliar piece of the stack is a reason for the next developer to avoid touching it.
3. Someone Must Own It
Every internal tool needs a named owner. Not a team. Not “everyone.” A specific person who is responsible for keeping it running, reviewing whether it’s still useful, and deciding when it should be retired.
Ownership doesn’t mean they do all the work. It means they notice when the tool breaks, they triage the fix, and they push back when someone suggests adding a feature that doesn’t belong. Without ownership, tools drift into neglect by default.
What We Actually Use
We keep our internal tooling deliberately small. Each tool exists because it solved a specific problem that was costing us real time.
Uptime Monitoring (Kuma)
We run Uptime Kuma on our own infrastructure to monitor client applications and internal services. Before Kuma, we found out about downtime when clients told us. That’s not a good look.
Kuma is self-hosted, lightweight, and does exactly one thing: checks whether services are up and alerts us when they’re not. We chose it because it’s simple enough that anyone on the team can configure a new monitor in under a minute, and it doesn’t try to be a full observability platform.
Sentry Integration With YouTrack
Error monitoring without a workflow is just a stream of notifications that people learn to ignore. We integrated Sentry with YouTrack so that errors automatically create trackable issues in the same system where all our project work lives. An error isn’t just logged — it enters the same triage process as any other ticket.
This was a deliberate choice to reduce context switching. The team doesn’t need to check Sentry separately. Errors flow into the workflow they’re already using.
SSO Synchronisation
Managing access across multiple client environments manually is tedious and error-prone. Our SSO sync tooling ensures that when someone joins or leaves the team, access is updated consistently across environments. It replaced a manual checklist that was reliable right up until someone forgot a step.
Struggling with internal tools that nobody uses? We help small teams build tools that actually stick. Let’s fix that →
What We Learned About Noise vs. Signal
We built a dev dashboard. It aggregated information from multiple sources into a single view: deployments, error rates, uptime status, recent commits, open merge requests. In theory, one place to see everything.
In practice, it was too much. The team’s feedback was direct: “Valuable concept, but the project board is easier to use.” The dashboard showed everything but highlighted nothing. It created noise instead of reducing it. People opened it, saw a wall of data, and closed it to go back to the tools they were already comfortable with.
The lesson was clear: aggregation is not the same as signal. Showing more information doesn’t help if the team still has to mentally filter it to find what matters. We pulled back. Rather than one central dashboard that tried to replace everything, we focused on keeping individual tools sharp and making sure each one only surfaced what required action.
We’re evaluating options for centralised logging, but with the same discipline: it needs to surface actionable information, not just more data. If it becomes another tab that people ignore, we’ll cut it.
Keeping It Lean
The hardest discipline with internal tools isn’t building them. It’s saying no to expanding them.
Every internal tool will attract feature requests from the team. Some are genuine improvements. Most are “wouldn’t it be nice” additions that increase the maintenance surface without proportional value. We’ve learned to ask a specific question before adding anything: “Will this save time this quarter, or is it interesting?”
Templates are a good example. We debated whether standardised templates across our tooling would save time. The answer was nuanced — they help for repeatable processes but add rigidity where flexibility matters. We adopted them selectively rather than universally.
Retirement is equally important. If a tool stops being used, shut it down. Don’t leave it running because someone might need it eventually. Dead tools that are still technically “available” confuse new team members and waste hosting resources. If it’s not actively solving a problem, it’s clutter.
Building internal tools that keep dying? We help small teams design and ship tools that stick — using the same principles above. Book a free 30-minute call →
Frequently Asked Questions
When should a small team build internal tools? When the time spent building it pays for itself within a quarter. If the pain is infrequent or mild, leave it manual.
How do you keep internal tools maintained? Use your existing stack, assign a named owner, and treat maintenance as a line item. Tools without owners die quietly.
What internal tools does Two Red Kites use? Kuma for uptime monitoring, Sentry integrated with YouTrack for error tracking, and SSO sync for access management. We also retire tools that stop earning their keep.