Build internal tools with AI: start with a request tracker

An AI app builder is useful for making a proposed process tangible. Instead of debating a request-tracker specification in the abstract, you can inspect a working screen and discover which fields, states and permissions are missing. This tutorial defines a small prototype, a test dataset and acceptance checks. It does not assume that generating an application makes it ready for company data.

First decide whether a new application is necessary

If a form and spreadsheet already collect the request, assign a reviewer and show its status, keep them for the pilot. A custom application becomes more interesting when users need a different interface or the approval process cannot be represented clearly in the current tools. Write that gap down before opening a builder.

Give the builder a bounded specification

Build a prototype internal request tracker using fictional data only.
Fields: request ID, title, requester, category, description, submitted date,
reviewer, status and reviewer decision note.
States: New, Needs information, Approved, Declined.
Requesters can submit and read their own requests. Reviewers can read and
decide requests assigned to them. Enforce permissions on the server.
AI may propose a category and a summary, both labelled as suggestions.
It must not approve requests or send external messages.
Include a history of status changes and a way to export the records.
Do not connect email, payments or real company systems.
Before implementing, list unresolved assumptions and the proposed data model.

Emergent is one candidate for turning this brief into a prototype. A developer using an existing framework is another. The same acceptance checks apply to either approach; changing the builder does not remove the need to define how the process should behave.

Use test requests that reveal mistakes

Test behaviour beyond the screen

1. Submit the same request twice and confirm what happens. Decide whether duplicates are allowed or detected.
2. Sign in as a different requester and try retrieving another request directly. Hiding a button is insufficient access control.
3. Have a reviewer decline a request, then inspect the record and history for the decision note and actor.
4. Remove the AI response or simulate a failed call. The form should still preserve the request for human review.
5. Export the sample records and confirm you can understand them outside the application.

What counts as a useful result

The result is an evaluated prototype plus a list of unresolved requirements. Show it to a requester and reviewer and watch them complete the sample process. Record confusing fields, missing information and incorrect permissions. Before production use, the responsible technical team must resolve authentication, data handling, backups, monitoring and maintenance. Those costs belong in the purchase decision.

If the prototype merely reproduces a form you already have, that is useful evidence too: keep the simpler system. For a broader comparison, start with the existing AI coding-tools guide; this page covers the narrower job of designing and checking an internal request workflow.