Turn a clear brief into a working app

What you’ll be able to do

• Write a bounded app brief with acceptance criteria.
• Build and test a one-file prototype.
• Separate a useful prototype from a production-ready application.

Get the idea

Describe behavior before appearance

A useful brief states who uses the app, what they need to do, and how you will check success. “Build a dashboard” leaves too much open. Specify fields, interactions, empty states, and limits.

Ask for small, testable slices

Build adding and listing tickets first. Then request a status toggle or a filter. Review each change against the acceptance criteria. Smaller edits make it easier to spot mistakes and explain the application.

Treat output as a draft

AI-generated code can contain bugs and insecure patterns. Validate inputs and insert user-provided text as text, not HTML. Confirm what the app actually stores. A working demo does not establish production readiness.

Try it yourself

1. Download the included request-tracker example and open it in a browser. Add two fictional requests and toggle one to resolved.
2. Give your assistant the brief below. Ask it to explain the implementation and name its limitations.
3. Compare its output with the starter: empty title rejection, keyboard-accessible controls, long text handling, and an empty state.
4. Ask for one improvement, such as filtering unresolved requests. Specify that filtering must not delete items or imply they were saved to a server.
5. Test an empty title, a very long title, repeated toggles, and a title containing <script>. That text must be displayed as text and never executed. Refresh the page and confirm the session-only data is cleared.

Example · commands or prompt

Build a single HTML file for an IT request tracker.
Audience: an IT administrator testing a prototype.
Fields: request title and priority (low, normal, high).
Actions: add a request and toggle open/resolved.
Requirements: semantic HTML, accessible labels, responsive layout,
input validation, and safe text rendering.
Keep data in memory only and explain that refresh clears it.
No accounts, analytics, external APIs, or hidden dependencies.
Include an empty state and manual test cases.

Try the working example

This interactive prototype uses fictional requests and temporary data. Refreshing clears the list.

Finish the lab

Close the prototype when finished. Do not use it for real work requests. Before production use, design server storage, authorization, retention, and appropriate testing.

Take this with you

Use AI to shorten the feedback loop, then verify the behavior yourself.

Go deeper

• Publish static applications on Azure

AI-assisted lesson · Reference links checked October 3, 2026. Exercises are teaching examples; they have not been executed against your Azure subscription.