Start from the decision, not the form
Name the decision the tool supports: approve an expense, assign a lead, close a ticket. A tool that speeds up a decision has a clear first version; a tool that "manages" something usually does not.
Then name the person who makes that decision and how often. Frequency tells you whether to build it at all.
Describe the data before the interface
List the fields, where they come from, and which one is the source of truth. Most failed internal tools are data disagreements wearing an interface.
Write five sample records. Real examples are more useful than a schema: they expose missing fields, duplicates, and the awkward cases that a clean description hides.
Let the first version be small
Ask for one screen that lists the records, one filter, and one action. Use it on real work for a week before adding anything. A small tool that is used beats a complete tool that is admired.
When something is missing, describe the workaround you did instead. "I exported to a spreadsheet and added a column" tells AI exactly what the next version needs.
Change it where the work lives
The reason to build internally is that requirements move. Keep the tool and the request in the same place so a change does not start with a new project.
Name each change by the work it unblocks, not by the component it touches. "I need to see last month's approvals in one list" is a change request; "add a date picker" is a guess about the solution.
Where this breaks
It breaks when nobody owns the tool, when the data source is disputed, and when the first version tries to replace a system of record. An internal tool should read from the source of truth, not become a second one.
It also breaks when access is an afterthought. Decide who can see the records before the first real data goes in.
How to run it on Sigla
Create one workspace for the tool, describe the decision and the five sample records, and let AI build the first screen. Use it, then ask for changes in the same workspace so the tool and its history stay together.
For the setup, read how to build your first app with AI. If you work from spreadsheets, the no-code app builder for analysts continues the same path.
FAQ
Do I need to know how the tool will be built?
No. You need to describe the job, the data, and the decision. The implementation is what AI produces and what you review by using it.
How long does a first version take?
It depends on the data, not the screens. If the fields and the source of truth are clear, a first version is quick; if they are disputed, fix that first.
What if the requirements change?
That is expected. Keep the change request next to the tool and describe the work it unblocks, rather than redesigning from scratch.
Can it replace our main system?
No. Treat it as a focused tool that reads from the system of record. Replacing that system is a different project with different risks.
Next step
Write the decision, the five sample records, and the one action the first version needs. Then ask for that version only.