A first app idea: a small internal request tracker

Choose a request that stays low stakes

A fictional equipment request is a useful prototype because you can define a clear beginning and end without processing payments or sensitive information. Describe who submits the request and who decides what happens next. Keep the first version away from health, payroll and disciplinary records. This is a proposed evaluation scenario, not evidence that a generated implementation is safe for a real workplace.

Define the record and status rules

The initial record could contain a short title, description, requested date and status. Give each request a stable identifier so an edit does not create a new request. Decide who can change its status and whether a closed request can reopen. Write those rules in the brief. Avoid adding chat, automated purchasing and attachment uploads until the basic record behaves as intended.

Test the complete use case

Submit one fictional request, reload, open it as the operator, change its status and confirm the requester sees the intended result. Then try a missing title and two quick submit clicks. Record whether one request or two exist afterward. Test the access boundary with separate authorized test users, not by guessing another person’s identifiers. A polished list view does not establish that the whole journey works.

Decide whether the pilot earns another phase

Ask a small, willing group to compare the working prototype with the existing process only after the basic checks pass. Observe which steps cause confusion and whether corrections remain possible. Do not turn opinions from a demonstration into adoption numbers. The next phase should solve a demonstrated problem, such as clearer status explanations, rather than adding features because the builder can generate more screens.

• Write the exact allowed status transitions beside the brief and test an attempted transition that should be rejected.