How to build an internal tool with AI that your team can rely on

The short answer

Write the spec before you write a prompt. Describe the problem in one sentence, decide what you will leave out, define the data model and the rules with worked examples, then build in three to five phases and run acceptance checks after each one.

AI app builders are good at turning precise instructions into working code. They are poor at guessing rules nobody wrote down: who may approve what, what happens when someone is on holiday, how a refund changes a commission that was already paid. A one-line prompt gets you a convincing demo. A spec gets you a tool your team can rely on.

This is the method every blueprint on this site follows. The examples below come from building the Approval Workflow from its own blueprint.

Which tools are a good fit

Good fits share three traits: a clear workflow, a small data model and a small team. Examples:

• Requests and approvals: purchase approvals, time off, access requests.
• Records with a next step: a CRM where every contact has a follow-up date, a hiring pipeline, client onboarding.
• Calendars and status: a content calendar, a weekly project status report.
• Calculations with rules: sales commissions, quotes with discount limits, software spend.

These need extra care in the spec: permissions, money, dates and time zones, notifications, imports, anything that runs on a schedule.

These are usually better bought than built: payroll and tax, anything with regulatory certification requirements, deep two-way integrations with many systems, real-time collaborative editing, and public products at scale.

Step 1: Write the problem in one sentence

Use the words of the person who has the problem, not the name of a product category.

"Purchase requests get lost in Slack, and nobody knows who approved what."

That sentence tells you what success looks like (nothing gets lost, every decision is recorded) and what does not matter (forms, branding, dashboards). Every later decision can be checked against it.

Step 2: Decide what you will leave out

The product you are replacing does far more than your team uses. Read its product pages and help center, list what it does, then write two short lists: what you keep and what you deliberately leave out.

For the approval workflow we kept a structured request form, routing by amount and category, a sequential approval chain, approve, reject or send back, segregation of duties, delegation, reminders, escalation, an append-only audit log, Slack approvals and CSV export. We left out a no-code form builder, a visual workflow designer, parallel branches, cost-centre coding, ERP integrations and file uploads.

Writing the "leave out" list matters as much as the "keep" list. It stops the AI from inventing features, and it tells the reader when they should buy the product instead.

Step 3: Define the data model before any screens

List every table and every field, with its type and constraints. A few rules prevent most bugs:

• Money is an integer number of cents. Never a floating-point number.
• Dates and timestamps are different things. A due date is a calendar date; "approved at" is a UTC timestamp. Say which time zone "today" is in.
• History is append-only. An audit log that can be edited is not an audit log. Say so, and say there is no API to change it.
• Notifications go through an outbox. Write each message to a table first, then send it. This makes email and Slack testable without real accounts, and retryable when a provider fails.

Step 4: Write the rules as numbered statements, with worked examples

Rules written as prose get interpreted. Rules written as numbered statements get implemented. "R2. A requester can never approve their own request (enforced by routing and checked again when the action happens)" leaves little room to guess.

For anything that computes a result, add worked examples with your sample data. The approval workflow spec includes a table like this:

Worked examples do two jobs. They show the AI exactly what the rule means, and they become your tests.

Step 5: Write seed data that exercises every rule

Name the people, their roles and their reporting lines, and create records that hit each rule: someone with no manager, an approver who is out of office, a request just over a threshold. With realistic seed data, every acceptance check can name a person and an expected result instead of saying "a user" and "it works".

Step 6: Split the build into phases

Send the whole spec as context, then build in three to five phases, one prompt per phase. A typical split:

1. Foundation: the data model with a real database, sign-in, admin screens, seed data, and a development-only "sign in as" switcher so you can test as different people.
2. The core flow: the main screens and the main rules, enforced on the server.
3. Notifications and integrations: email and Slack through the outbox.
4. Time and export: reminders, escalation, scheduled jobs (with a development-only way to move the clock forward), CSV export.

Each prompt should say what to build, which sections and rules to follow, what not to build yet, and end with: "When you're done, list what you built and anything in the spec you had to interpret." That last line is where most problems surface.

Step 7: Run acceptance checks after every phase

Each phase ends with checks you can run by clicking through the app. Good checks name the person, the action and the visible result:

• "Signed in as Ana while Maya's step is active, there is no Approve button and a direct API call is refused."
• "Ana tries to reject without a comment and is blocked. She sends back with a comment instead. Jo sees 'Changes requested' and the comment."

Do not move to the next phase until the current phase passes. Problems found in Phase 1 are cheap; the same problems found in Phase 4 mean rework across everything built on top.

Step 8: When the AI has to guess, fix the spec

Every time the builder interprets something, ask whether the spec should have said it. When we built the approval workflow from its blueprint, the build passed all 34 acceptance checks, and it also exposed five gaps in the spec:

1. Escalation could hand a step to someone who owned a later step, so they would be asked to approve the same request twice.
2. The spec did not say what happens when a rule's approver is inactive at the moment a request is submitted.
3. The admin screen allowed reporting loops (A manages B, B manages A), which breaks routing.
4. Reassignment and escalation did not say whether the reminder clock restarts.
5. Times in Slack messages showed in UTC instead of each person's local time.

None of these were exotic. They are the edges every real team hits within a month: people change roles, go on holiday, leave. Each one became a numbered rule in the published blueprint. Gaps cluster in the same places in most tools: changes to people and permissions, time, and how things are displayed outside the app.

Before you put it in front of your team

A tool that passes its checks on a development server still needs:

• Real sign-in. Use your platform's built-in auth or Google sign-in limited to your company domain. Remove the "sign in as" switcher from production.
• Permissions on the server. Hiding a button is not a permission check. Every rule about who can do what must be enforced in the API.
• A managed database with backups. Test builds often use SQLite on one machine; production should use your platform's managed database with the same schema.
• A real email provider connected to the outbox, with failures retried.
• An owner. Someone who will fix it when it breaks and change it when the process changes.
• An export. Your data should leave as a CSV in one click, so the tool never traps you.

Which AI builder should you use?

Any builder that accepts a long document as context and can create a web app with a database will work with a good spec. The trade-off is mostly about where the code lives:

• Hosted app builders (for example Lovable, Replit or Type) host the app for you and are the fastest way to get something your team can open.
• Coding assistants (for example Claude, ChatGPT, Cursor or Claude Code) produce code you keep in your own repository and deploy wherever you like.

Our build tests use Claude. The acceptance checks are how you find out whether your builder read the spec the same way.

Questions people ask

Can AI really build business software?

Yes, for internal tools with a clear workflow and a modest data model. The limiting factor is the precision of the instructions, not the AI's ability to write code. Our build of the approval workflow from its blueprint passed all 34 browser acceptance checks and has 38 automated tests.

How long does it take?

The coding is no longer the slow part. Most of the time goes into deciding the rules and checking each phase. Each blueprint on this site shows an estimate; the four-phase approval workflow is estimated at one to two hours for someone working with an AI builder from the finished spec.

Do I need to know how to code?

Not to build the first version with a hosted builder. You do need to read what the builder tells you it interpreted, run the acceptance checks, and own the tool afterwards. For production sign-in, permissions and backups, it helps to have someone who has run software before review the setup.

Where do I start?

Pick the tool where your team pays per seat for a large product and uses a small part of it. Then start from a blueprint or write your own spec using the steps above.