AI Automation · 2026-07-22
Building an Internal Tool With AI: A Practical Case Study
How we built an internal ops tool with AI in a weekend—the stack, the workflow, real numbers, and what actually worked.
TL;DR
We built an internal client-reporting tool in a weekend using AI as the primary coder. The workflow: scope one painful task, write a tight spec, let Claude generate the code in small chunks, test each chunk immediately, and ship a rough v1 to real users within days—not a polished app, a working one.
The tool solved one problem: pulling SEO ranking data from three sources into a single client dashboard. Our team was doing this by hand every Monday—roughly 4 hours a week across two people. That repetitive, well-defined pain is exactly what an internal AI-built tool should target first.
We started with a one-page spec, not a prompt. It listed the inputs (three API keys), the output (one CSV plus a simple web view), and the five rules for merging the data. Writing this took 40 minutes and cut the back-and-forth with the AI dramatically. Vague prompts produce vague code; a spec produces something you can test.
Stack was deliberately boring: Python for the data pulls, a single Flask file for the view, SQLite so there was no database to provision. We used Claude to write it and Cursor to edit inline. Boring stacks matter here—the AI has seen thousands of examples, so it makes fewer mistakes and you can read the output.
We generated code in chunks of one function at a time and ran each one before asking for the next. When a Google Search Console call failed, we pasted the exact error back in and got a working fix in two turns. This tight loop—generate, run, paste the error, repeat—is where most of the real work happened.
Total build time was about 11 hours over three days, including debugging. The tool now saves roughly 3.5 hours a week. It paid for itself in the first month, and because the code is simple, a non-engineer on the team can tweak the merge rules without our help.
The honest limits: the AI wrote confident code that silently dropped rows when one API returned nulls. We only caught it because we checked the output against the manual numbers for two weeks. Never trust an AI-built internal tool until its output matches the process it's replacing.
If you run a small business or Shopify store, start with your most repetitive weekly task, write a one-page spec, pick a boring stack, and build the ugliest version that works. You do not need to be an engineer—you need to be specific, test everything, and verify the output before you rely on it.
Frequently asked
Do I need to know how to code to build an internal tool with AI?
No, but you need to be specific and test everything. You can build a working tool without coding, but you must verify its output against your existing process before relying on it.
How long does it take to build a simple internal tool with AI?
A focused, single-purpose tool typically takes 10-15 hours over a few days, including debugging. Ours took about 11 hours across three days.
What tasks are best for an AI-built internal tool?
Repetitive, well-defined tasks with clear inputs and outputs—like merging data from several sources or generating a weekly report. Avoid fuzzy tasks that require judgment.
Can I trust the code AI generates for internal tools?
Not blindly. AI writes confident code that can silently fail on edge cases, so run its output alongside your manual process for a couple of weeks before depending on it.
Free, concrete, yours to keep
Want this done for you — properly?
Get a free audit of your rankings and AI-answer presence. Real findings within days, no sales deck.