We earn commissions when you shop through the links below.
If you’ve ever spent three weeks building a CSV importer your finance team uses twice a month, you already understand the pain. Knowing how to build internal tools with AI quickly is one of the most valuable skills a developer can have right now. The gap between “we need a tool” and “here it is” has collapsed dramatically, and teams that figure this out are shipping internal software in days instead of months.
This post walks through my actual workflow for spinning up internal tools fast — from ideation to deployment — with real code and honest opinions about what works.
Why Internal Tools Are the Perfect AI Use Case
Internal tools have a few properties that make them ideal for AI-assisted development:
- Low aesthetic bar. Nobody cares if the admin panel looks a bit rough. It just needs to work.
- Well-defined scope. “Show me all orders over $500 with a button to refund them” is specific enough for an AI to get right on the first or second try.
- High repetition. CRUD interfaces, data tables, forms, API wrappers — this is boilerplate territory where AI excels.
- Forgiving users. Your colleagues will tolerate a bug. Your customers won’t.
This combination means you can move fast, iterate in production, and still deliver real value.
My Stack for Fast Internal Tool Development
Before diving into the workflow, here’s what I reach for:
- Next.js — full-stack, file-based routing, API routes built in
- Tailwind CSS + shadcn/ui — good-enough UI with zero design decisions
- Prisma + PostgreSQL — schema-first, readable queries
- Cursor — AI-native editor that understands your whole codebase, not just the file you have open
- Make — for wiring up automations around the tool (Slack alerts, email triggers, data syncs)
The combination of Cursor and Make covers roughly 80% of what I need when building internal tools. Cursor handles the code generation and iteration; Make handles the glue logic so I don’t have to write webhook handlers from scratch every time.
Step 1: Write the Spec as a Prompt
The biggest mistake I see developers make is jumping straight into code without writing down what the tool actually needs to do. With AI-assisted development, your spec becomes your prompt, so it pays to be precise.
Here’s a real example. A client needed an internal tool to manage affiliate payouts. I wrote this spec:
Build a Next.js admin page at /admin/payouts that:
- Fetches all affiliate records from the `affiliates` table where `status = 'pending'`
- Displays them in a sortable table with columns: name, email, amount_owed, last_sale_date
- Has a "Mark as Paid" button per row that sets status to 'paid' and records paid_at timestamp
- Has a bulk "Export CSV" button for the filtered rows
- Requires the user to be authenticated (use existing NextAuth session)
- Shows a success toast on action completion
I dropped this into Cursor’s Composer and got a working scaffold in about four minutes. Not perfect — I had to fix a type error and adjust the CSV export headers — but the heavy lifting was done.
Step 2: Generate the Scaffold with AI
Using Cursor’s Composer (cmd+I on Mac), I feed it the spec and let it generate the full component, API route, and any Prisma queries it needs. The key is giving it context about your existing codebase — Cursor indexes your project, so it’ll pick up your existing auth patterns, your Prisma client location, and your component conventions automatically.
Here’s the kind of API route it generates for the payout update action:
// app/api/payouts/[id]/route.ts
import { NextRequest, NextResponse } from 'next/server';
import { getServerSession } from 'next-auth';
import { authOptions } from '@/lib/auth';
import { prisma } from '@/lib/prisma';
export async function PATCH(req: NextRequest, { params }: { params: { id: string } }) {
const session = await getServerSession(authOptions);
if (!session) {
return NextResponse.json({ error: 'Unauthorized' }, { status: 401 });
}
const affiliate = await prisma.affiliate.update({
where: { id: params.id },
data: {
status: 'paid',
paid_at: new Date(),
},
});
return NextResponse.json(affiliate);
}
This is exactly what I’d write myself — which is the point. AI handles the rote work; I review, adjust, and move on.
Step 3: Iterate Fast with Targeted Prompts
The first generation is rarely the final version. But with AI, iteration is cheap. Instead of editing the code manually, I prompt Cursor with specific change requests:
- “Add a date range filter to the table that filters by last_sale_date”
- “Show a confirmation modal before marking as paid”
- “Add pagination, 25 rows per page”
Each of these takes under a minute to apply and review. This is the core loop of how to build internal tools with AI quickly — write a tight spec, generate a scaffold, then iterate with conversational prompts rather than manual editing.
Step 4: Wire Up Automations with Make
Most internal tools don’t live in isolation. The payout tool needs to notify the finance Slack channel when a batch is marked paid. Rather than building a Slack integration from scratch, I set up a Make scenario that listens to a webhook my Next.js app fires.
The webhook call is straightforward:
// After updating payout status
await fetch(process.env.MAKE_WEBHOOK_URL!, {
method: 'POST',
headers: { 'Content-Type': 'application/json' },
body: JSON.stringify({
affiliateName: affiliate.name,
amount: affiliate.amount_owed,
paidAt: affiliate.paid_at,
}),
});
Make picks this up and routes it to Slack, logs it in a Google Sheet, and triggers a confirmation email to the affiliate. Zero extra backend code on my end. This kind of integration layer is where Make genuinely earns its keep for internal tooling projects.
Step 5: Deploy and Share
Internal tools don’t need elaborate deployment pipelines. My default is Vercel for the Next.js app (zero config, instant preview URLs) and Railway for the PostgreSQL database. Railway’s managed Postgres spins up in under a minute and gives you a connection string you can drop straight into your environment variables. For a tool that a handful of colleagues will use, this is more than enough.
What AI Gets Wrong (and How to Catch It)
Being honest: AI-generated internal tools have failure patterns you should watch for.
- Authorization gaps. AI will add authentication checks, but it often misses row-level authorization. Always verify that users can only see and modify data they’re supposed to.
- Missing error states. Generated UIs often handle the happy path only. Add loading states, empty states, and error boundaries manually.
- N+1 queries. Prisma queries generated by AI sometimes fetch related data inefficiently. Check the generated queries against your actual data volume.
- No input validation. Always add Zod or similar validation to API routes, even for internal tools. Your colleagues will find creative ways to break things.
None of these are dealbreakers — they’re just a checklist to run through before you hand the tool off to your team.
The Real Productivity Gain
Knowing how to build internal tools with AI quickly isn’t about replacing engineering judgment — it’s about removing the friction that causes good ideas to die in the backlog. When a tool takes three days instead of three weeks, it actually gets built. When iteration is cheap, the tool actually gets improved based on feedback.
I’ve shipped more internal tooling in the past year than in the previous three combined, and the quality is higher because I have time to think about the right abstractions instead of hand-writing data tables.
If you’re not already using an AI-native editor like Cursor for this kind of work, that’s the single highest-leverage change you can make to your workflow today. Pair it with Make for automation logic, and you have a setup that handles the vast majority of internal tool requirements without reinventing the wheel every time.
Start with the smallest tool your team actually needs, write a tight spec, and ship something by end of week. The methodology reveals itself quickly once you’re in it.