Internal Tools Are the Next Frontier of AI
- Aug 23
- 7 min read
Building hyper-focused internal applications that replace generic dashboards with tools your team actually needs
The most valuable AI-powered tools for your business aren't the general-purpose ones. They're the ones built specifically for the way your team actually works.
The Problem with Generic Dashboards
Most companies run on a stack of third-party SaaS tools. CRMs, project management platforms, reporting dashboards, spreadsheets all stitched together to solve an immediate issue or answer a specific need. These processes calcify into requirements. New hires are onboarded into them without anyone questioning why they exist in the first place. These third-party tools are designed for a broad market — which means the workflows were engineered to fit the restraints and capabilities of the specific tool.
The workaround becomes the job. Someone exports a CSV, drags it into another tool, reformats the columns, runs a formula, pastes the output into a deck. And it happens dozens of times a day, across every department. Want to customize that workflow within the third-party app? You first need to upgrade to Enterprise Gold for an extra $5k a year.
I've watched colleagues at Inlightened do a version of this constantly. In an effort to compare columns in a spreadsheet, they drag and drop the Excel file into Claude, an agent is created and works on the task, burning through tokens. A result is returned. Repeat from scratch next time because nothing was saved, nothing was connected, and the process lived entirely in the conversation window.
The work gets done. But it's slow, inconsistent, and expensive — in both time and tokens.
What I Built Instead
At Inlightened, I've been building hyper-focused internal applications that replace that drag-and-drop cycle with tools that are reusable, connected, and cheap to run. Here's what that looks like in practice:
The first tool is a list-matching application. When a client brings us a universe of potential research participants, we need to cross-reference it against our expert panel — hundreds of thousands of enriched profiles — and surface the strongest matches quickly. Before, this was a manual, multi-step process. Now it's an application: structured input, deterministic logic, limited AI interaction, output in seconds. It runs the same way every time. The token cost is controlled and predictable. And the results are auditable — my colleagues can see exactly why a match was surfaced.
The second tool I built was a feasibility calculator. Before a client commits to a research project on our platform, they want to know: what's the realistic likelihood this succeeds? We have the data to answer that — past project performance, panel depth, specialty distribution. We have all of this nuance in our database but no easy interface to pull these insights. I built a tool that pulls it together, runs the calculation, and produces a confidence estimate a Sales Associate can actually use in a client conversation. No spreadsheet. No manual lookup. No AI hallucinating a number it made up. The scripts, equations, and weighting logic were developed with the help of AI, but when the tool runs there is virtually no token use. And even better, we can audit the results, confirming that the experts surfaced are real and in our database. The next step is a direct handoff — that list goes to our Recruiters, who can begin outreach the moment a project is green lit, with no manual transfer in between.
The third tool is a Stripe Identity automation. To verify experts on our site, we use Stripe's ID verification feature — experts submit a photo of themselves alongside a government-issued ID to confirm they're a real person. It cuts down on fraud almost completely, but processing those requests one by one was a genuine drain on the team. Before the tool existed, someone had to manually initiate each identity check, track its status across a growing list of experts, and follow up when results came in. I built an application that connects to our Stripe account and handles the whole flow: bulk sending identity requests, monitoring and tracking progress, surfacing results in one view, and triggering notifications when an expert passes or fails. What was a time-consuming manual process is now largely automated. The time savings are significant, and the security posture is meaningfully stronger — fraud attempts that previously required manual detection are now caught systematically.
What these tools share is a design philosophy: I designed the architecture and authentication layer myself, used Claude Code to build the initial scripts, and ended up with applications that are low-cost, reusable, and safe — not one-off experiments that disappear after the conversation closes.
AI as a Collaborator in the Build, Not Just the Output
I use Claude Code to build the complex analytical tools — the matching scripts, the feasibility calculators, the integrations. I'm the architect. I design what the system needs to do, how data flows through it, what the authentication model looks like, what gets sent to an LLM and what doesn't. Claude Code handles the implementation work I'd otherwise spend days writing by hand — a dramatically faster path from architecture to working software.
These are MVPs — deliberately scoped, designed to be audited and improved by the dev team before they go anywhere near production. That oversight is part of the design, not an afterthought. But the MVP stage means my colleagues don't have to wait for a full development cycle to see their workflows improve. The tools are in their hands while the production version is being planned.
Third-Party Tools Don't Disappear — They Become Infrastructure
I'm not suggesting companies stop using Salesforce or HubSpot or whatever reporting platform they've standardized on. Those tools store data, handle permissions, maintain audit trails, and do a hundred other things that would be expensive to replicate. What I am suggesting is that the dashboard stops being the primary interface.
The tools my team uses most aren't dashboards — they're purpose-built applications that pull from the sources that matter, run the logic that's specific to our business, and push results to wherever they're needed. If the output belongs in a Salesforce record, it goes there via API. If it belongs in Monday or Airtable, same result. The third-party platform stays in its lane as infrastructure. The interface is purpose-built for the task.
This is where the subscription model for SaaS starts to look different. Not as a dashboard you log into — as a toolkit your internal applications connect to. The data lives there. The logic lives in the tool you built for the workflow.
What This Requires
None of this works without deliberate architectural thinking upfront. Building reusable internal tools is not the same as having an AI generate a one-off script. The decisions that matter happen before a line of code gets written:
What data does this tool need access to, and what should it never touch?
Who uses this, and how do we scope their permissions accordingly?
Where does AI actually add value in this workflow — and where does deterministic logic serve better?
How does output get to the people who need it, and in what form?
What does it cost to run this at scale, and is that cost fixed or variable with usage?
How does this get handed off, audited, and maintained when it graduates from MVP to product?
Get those decisions right and you end up with something durable: a tool that runs reliably, costs predictably, and gets better over time as your team uses it. Get them wrong and you end up with a sophisticated script that nobody trusts, nobody maintains, and nobody can explain.
The architecture is the work. Claude Code handles the implementation.
The Broader Pattern
What I'm describing at Inlightened is a small-scale version of a shift I think is coming more broadly. As AI makes implementation cheaper and faster, the constraint on internal tooling is no longer engineering capacity — it's knowing what to build and designing it responsibly.
Every company has workflows that are specific to how they operate: the way they qualify a lead, the way they match supply to demand, the way they estimate risk on a new engagement. None of those workflows map perfectly to a generic SaaS product. They never did. The workaround was accepting the friction.
That workaround is becoming optional. The tools that fit your business exactly are now buildable by a small team — or even a single product-minded person — without a full engineering organization behind them. The ceiling on what's possible has moved. The question is whether you're designing for it deliberately or still dragging spreadsheets into chat windows and starting over every time.
The Next Frontier Is Already in the Building
Something unexpected has started happening. Colleagues who have never written a line of code — people who live inside these tools every day, who feel every friction point, who have domain expertise no interview or feature ticket fully captures — are asking about Claude Code.
That's not a problem to manage. That's an opportunity.
The people best positioned to improve these tools aren't necessarily developers. They're the ones who use them. They know what's missing, what's clunky, what would save them an hour on a Tuesday. The question I'm working through now is how to plug them into a developer workflow without creating overhead or losing control — getting them set up in GitHub, treating them as junior contributors, giving them a path to ship improvements rather than filing requests and waiting.
It's a harder problem than it sounds. The goal isn't to turn everyone into an engineer. It's to make sure the people with the most relevant knowledge have a real way to act on it. I'll write more about that next.
------------------------------------------------
Lucas Longacre is Head of Product at Inlightened and co-founder of Mebot AI. He writes about responsible AI implementation in healthcare market research and beyond. Earlier pieces in this series: There's No Dropdown for This and The Best of Both Worlds.
Comments