Using Claude Code to build internal business apps: what it's genuinely good at, and where it will hurt you

I build internal business software — dashboards, approval flows, integration layers, the unglamorous systems a company actually runs on. For the past year most of that has been written with an AI coding agent in the loop.

Here's what's true, from shipping rather than from demos.

Where it genuinely collapses the timeline

Integration glue. This is the strongest case by a wide margin. Writing a typed client for the QuickBooks API, mapping their field names to yours, handling pagination and token refresh — that used to be two days of documentation archaeology. It's now an afternoon. The work is well-specified, tedious, and heavily represented in training data. Perfect fit.

The second through tenth version of a form. Internal tools are mostly forms and tables. Once the first one exists with your conventions, generating the rest is nearly free.

Migrations and refactors with a clear rule. "Every API route should validate its input with this schema pattern" is the kind of instruction that used to mean a boring week.

Test scaffolding. Not the assertions that matter, but the fixtures and setup around them.

Where it will hurt you

Anything involving money, permissions, or an audit trail. These systems have requirements that don't appear in the code — a bookkeeper's expectation about how a reversal posts, or a rule that a manager can approve up to a threshold but not their own expense. An agent will produce something that compiles, passes tests, and is subtly wrong in a way you find during month-end close.

Data modeling under real business rules. Given a vague prompt, you get a schema that handles the happy path. Real businesses are made of exceptions. The model doesn't know that this client bills three of their customers on a different cycle for historical reasons.

Anything where "looks right" and "is right" diverge. A dashboard with plausible numbers is more dangerous than a broken one, because nobody investigates it.

The guardrails that decide the outcome

These are the difference between a fast build and a slow cleanup.

1. Types and schema validation at every boundary. The agent respects a strict type system. Give it a loose one and it'll take the freedom. Zod or equivalent on every input.

2. The database is yours to design. I write the schema by hand. Every time. It's the one artifact that's expensive to change later, and it's where business rules actually live.

3. Small, reviewable diffs. A 40-file change is unreviewable, and unreviewed AI code is how you get systems nobody understands. Working in small increments isn't slower; it's the only speed that includes reading.

4. A written spec before generation. Not for the agent's benefit — for yours. If you can't write down what "approved" means in your expense flow, the agent will invent a definition and you'll inherit it.

5. Tests on the rules, not the plumbing. Don't test that a route returns 200. Test that a $5,000 expense from a manager with a $2,000 limit gets rejected.

What I tell clients about this

Two things, honestly.

First: AI is why an internal app now takes weeks instead of a quarter, and why it can cost less than the software it replaces. That's a real change, not marketing.

Second: it doesn't reduce the judgment required, it concentrates it. The time you save on typing gets spent deciding what should be built and verifying that what got built is correct. If a shop is using these tools to skip the second part, you'll see it in about eighteen months, when nobody can explain how the system works.

That's the same failure mode as every undocumented system I've inherited in twenty years. The tool is new; the mistake isn't.

---

The takeaway: treat the agent as an extremely fast junior who has read everything and remembers nothing about your business. Give it a schema, a spec, and a small scope — then read what comes back.