Small teams waste an absurd amount of time on manual work that could be solved with a simple internal tool. I see it constantly: spreadsheet hell, email chains to track approvals, copying data between systems, manual report generation every Monday morning. The work gets done, but it's slow and error-prone.
The usual answer is "hire a developer" or "buy software." But hiring a developer for a small internal tool is expensive and slow — you're looking at weeks of back-and-forth and thousands of dollars for something that might only save you three hours a week. And off-the-shelf software rarely fits exactly what you need, so you end up adapting your workflow to the tool instead of the other way around.
Over the past year I've been building internal tools with Claude Code for small teams in Vancouver — agencies, service businesses, consulting firms — and the speed and cost difference is dramatic. What used to require a $10,000 contract and a six-week timeline now takes me two days and costs a fraction of that. Here's how I'm doing it and what kinds of tools actually make sense to build this way.
What Counts as an Internal Tool
Before I get into the how, it's worth defining what I mean by "internal tool." I'm talking about web-based software your team uses to get work done faster. Not customer-facing products, not apps with thousands of users — just the operational plumbing that keeps a business running smoothly.
The most common types I build:
- Admin dashboards — a single interface where you can see key metrics, update records, and manage workflows without touching a spreadsheet
- Approval workflows — systems where requests (expense approvals, content sign-offs, vendor onboarding) move through defined steps with notifications at each stage
- Data sync tools — scripts that pull data from one system (your CRM, your accounting software, a Google Sheet) and push it somewhere else on a schedule
- Client portals — simple login pages where clients can view project status, upload files, or access deliverables without emailing back and forth
- Custom reporting interfaces — tools that pull data from multiple sources, apply your specific calculations, and output a formatted report
These aren't complex enterprise systems. They're single-purpose tools that solve one specific workflow bottleneck. And that narrow scope is exactly why Claude Code works so well for building them.
Why Claude Code Works for This
The reason I can build internal tools with Claude Code faster than a traditional developer isn't because the code is better — it's because the iteration speed is faster and the requirements are simpler.
When you hire a developer for a custom internal tool, a lot of time gets spent on requirements gathering, wireframes, revision rounds, and testing edge cases. That makes sense for a customer-facing product where failure is expensive. But for an internal tool used by five people, you can afford to be more pragmatic. You build a working prototype, test it with the team, and fix whatever doesn't work. The tolerance for "good enough" is much higher.
Claude Code fits that workflow perfectly. I can go from a Slack message describing the problem to a working prototype in four hours. The prototype won't have perfect error handling or a polished UI, but it will do the core job. Then we test it, I refine it, and within a day or two the team is using it in production.
The fastest internal tool build I've done was for a marketing agency that needed to track client approval status across 20 active campaigns. They were managing it in a shared Google Sheet with color coding. I built them a simple dashboard with a PostgreSQL backend and a web interface where they could update status, add notes, and filter by client or campaign type. Start to finish: six hours.
That's not possible with traditional development, where you'd spend the first two hours just setting up the development environment and deciding on a tech stack.
Real Examples from Client Work
Here are three actual tools I've built in the past six months, with rough timelines and what they replaced.
Onboarding Checklist System (Built in 8 hours)
A consulting firm was onboarding 2–3 new clients per month. Each onboarding involved 12 steps spread across multiple people: contracts signed, Slack channel created, access provisioned, kickoff scheduled, initial deliverables defined. They were tracking it in a shared Notion doc, and things kept falling through the cracks.
I built them a checklist system where each new client gets a dedicated page. As team members complete steps, they check them off and the system sends Slack notifications to whoever owns the next step. The operations manager can see all active onboardings in one view and flag anything that's overdue.
Tech stack: Node.js backend, SQLite database, simple HTML/CSS frontend, Slack webhooks for notifications. No authentication needed because it's behind their VPN. Total build time including testing: eight hours.
Invoice Approval Workflow (Built in 12 hours)
A creative agency had a painful invoice approval process. Vendors would email invoices, someone would forward them to the finance lead, the finance lead would check the budget and either approve or kick it back, then someone would manually enter it into QuickBooks. On average this took 3–5 days per invoice.
I built a tool where vendors submit invoices through a form. The invoice gets assigned to the relevant budget owner for approval. Once approved, it generates a CSV that can be imported directly into QuickBooks. The whole process now takes 24 hours on average, and there's a clear audit trail of who approved what and when.
This one took 12 hours because it needed proper user authentication (budget owners log in to approve invoices) and file uploads (for invoice PDFs). But even at 12 hours, it was a $1,500 project instead of the $8,000–12,000 a traditional developer would have quoted.
Content Calendar Sync Tool (Built in 5 hours)
A social media agency manages content calendars in Notion but needed to sync approved posts to a Google Sheet that their scheduling tool reads from. They were doing this manually every Monday — copying 20–30 posts from Notion to Sheets, one by one.
I built a script that runs daily, pulls all posts with "Approved" status from their Notion database via the API, and writes them to the Google Sheet in the exact format their scheduling tool expects. It runs on a $5/month server and saves them about 90 minutes of manual work every week.
This is the simplest category of internal tool — pure automation with no UI. But it's also the highest ROI, because the time savings compound every week.
What Claude Code Can't Do (Yet)
I want to be direct about the limits, because not every internal tool is a good fit for this approach.
If you need real-time collaboration (think Google Docs-style simultaneous editing), Claude Code isn't the right tool. The WebSocket and state synchronization logic required is complex enough that you're better off using an existing framework or hiring someone who specializes in that.
If your tool needs to handle sensitive data like payment processing or medical records, you need a real engineer who understands security architecture. I can build the interface, but I won't take responsibility for PCI or HIPAA compliance — that's beyond the scope of what's appropriate for rapid prototyping.
And if your internal tool is likely to scale to hundreds of users or handle thousands of requests per day, you should plan for that from the start with proper infrastructure. Claude Code can build the MVP, but you'll need a developer to refactor it for scale.
The sweet spot is tools used by 5–20 people, with straightforward logic, where speed and cost matter more than polish.
How to Know If You Need One
Here's a simple heuristic: if your team is doing the same manual task more than twice a week, and the task follows a consistent pattern, it's probably worth automating.
Good candidates for internal tools:
- Copying data between two systems on a schedule
- Generating a weekly report by pulling numbers from three different sources
- Tracking the status of something (projects, invoices, requests) across multiple stages
- Collecting structured information from team members or clients via forms
Bad candidates:
- One-off tasks that only happen quarterly
- Tasks that require heavy human judgment at every step
- Processes that are still changing every month (automate after it stabilizes)
The break-even point is usually around 10–20 hours of manual work saved over three months. If the tool saves your team more than that, it's worth building.
Getting Started
If you think your team could benefit from a custom internal tool but you're not sure where to start, here's what I'd recommend:
- Pick the single most painful manual task your team does every week
- Write down the exact steps involved — who does what, in what order, and what happens at each decision point
- Identify where the data lives (spreadsheets, CRM, email, Slack, etc.)
- Reach out and describe the workflow — I'll tell you if it's a good fit for automation and what a realistic timeline and cost would look like
Most of the internal tools I build are scoped and delivered in under a week. If you want to see whether this approach makes sense for your team, book a call and we can walk through a specific workflow together. I've also written about when to use Claude Code versus hiring a traditional developer and how to get started with Claude Code if you want to try building something yourself first.
The tools are here. The question is just which workflow you want to take off your team's plate first.