What should you define before AI builds an internal tool?
AI can help build an internal tool, while useful software still needs clear records, permissions, rules and tests. Begin with one job, define a completed result and inspect the generated interface against realistic examples. Connect later modules through shared identifiers, and review consequential actions before the tool changes important business records.
Keep these in mind
- Define the workflow before refining the interface.
- Test who may see and change each kind of record.
- A working demo needs an owner for updates, recovery and data export.
Begin with a job, not an empty prompt
“Build our operations system” leaves the most important decisions unstated. “Help the workshop track repair jobs from intake to collection” is a better beginning. It names the people, records and transitions the tool must handle.
For a fictional repair shop, a job needs a job number, customer, item, reported issue and current stage. The owner may later add photographs, a parts estimate and a collection date. Introducing these deliberately is safer than creating a new field every time a differently worded note arrives.
Write the rules in ordinary sentences
Try: “Technicians can update diagnosis and work status. Only a manager can approve a price change. A job cannot be marked collected without a collection confirmation.”
These sentences are understandable to the team and can become acceptance tests for the application. The generated screen should make those rules visible. A disabled action can explain what is missing.
A price change can show the previous and proposed amounts. A neat collection button that bypasses the business rule is not a finished feature.
Use a compact specification
The following specification describes a fictional repair queue. Use it as a starting point for deciding which records, permissions and exceptions your own application must handle.
| Part | Decision | Example test |
|---|---|---|
| Records | One job has one stable identifier | Two jobs for Rahul remain separate |
| Stages | Intake, diagnosis, approval, repair, collection | An unapproved estimate stays blocked |
| Access | Technicians see assigned jobs | A restricted user cannot export all customers |
| Corrections | Reopen with reason and manager review | A mistaken collection is traceable |
| Exit | Export jobs and attachments | Another tool can read the exported sample |
Generated software still needs secure development
NIST’s Secure Software Development Framework describes security practices across the development lifecycle. The buyer’s implication is straightforward: code created quickly still needs review, testing and a way to address vulnerabilities. The method used to write it does not replace those responsibilities.
GitHub’s security-feature documentation describes tools for dependencies, secrets and code security. Scanning can support a review, but a clean scan does not prove the business permissions are correct. Test that a customer cannot see another customer’s repair and that a technician cannot approve their own restricted price change.
Try a complete journey with difficult examples
Run a fictional job from intake through collection. Then try a customer with the same name, a cancelled repair, an unavailable part and an estimate changed after approval.
Ask someone who did not write the prompt to use the application. Their confusion often reveals a missing state or unclear label.
Check operations too. Who receives an error? Can the owner recover an accidentally removed record?
Does the app still work on the actual phone used in the workshop? An internal tool becomes valuable through these ordinary details, not merely through the speed of its first generated screen.
Keep modularity understandable
Each module should add a clear capability, such as repair intake or parts requests. Use shared identifiers for customers and jobs. Separate versions of Rahul and separate job numbers fragment the business picture.
Share the underlying identifiers across modules. Agree on the core records before expanding.
- Choose one workflow and define its beginning and end.
- Specify records, permissions and allowed transitions.
- Build a small version with fictional data.
- Test normal work, mistakes and restricted access.
- Assign maintenance and export responsibilities before release.
Common questions
How can an owner explain an internal tool without writing code?
Describe its users, required records and permitted decisions. Add completed-job examples and important exceptions. Those concrete cases help an implementation team evaluate whether the tool follows the intended rules.
When should a new module reuse an existing record?
Reuse the same customer, order or job identity when modules refer to the same real-world work. Define which module owns each fact and how corrections travel. Separate duplicate lists make a polished application harder to operate and report on.
Sources & further reading
Primary references for the facts and frameworks discussed. Worked examples and recommendations are Daltn’s own analysis.
- NIST Secure Software Development Framework ↗
Provides secure development lifecycle practices.
- GitHub security features ↗
Describes dependency, secret and code-security tooling.
Published by the team building Daltn. Comparisons are first-party analysis, not independent reviews. Our editorial approach.