Reviewed July 11, 2026. This is a worked planning example, not a promise that one prompt will produce production-ready software.
An app idea becomes buildable when another person can tell who uses it, what they can do, what the system remembers, and how everyone knows it worked. You do not need a 90-page requirements document. You need a compact specification that removes the most expensive ambiguity.
We will turn one napkin-sized idea—“a portal where customers can track repair jobs”—into a testable first-release plan. The same method works whether you build with App9, another AI builder, a no-code tool, or a software team.
Step 1: rewrite the idea as an outcome
Napkin idea: Make a portal for our appliance-repair customers.
Product outcome: Customers can submit a repair request with appliance details and photos, then see its current status without calling the office. Coordinators can review requests, assign a technician, schedule a visit, and send customer-visible updates while keeping internal notes private.
The second version names the users, the work, the information, and the privacy boundary. It also suggests a measurable launch result: fewer “what is happening with my repair?” calls and a completed request flow customers can use without staff assistance.
Step 2: define the first release—and the parking lot
A first release is a complete thin slice, not a warehouse of half-built features. For the portal, the slice begins when a customer needs help and ends when the job is marked complete.
| Build now | Park for later | Why |
|---|---|---|
| Email sign-in and account recovery | Social sign-in | One dependable identity path is enough to test demand. |
| Appliance and repair-request forms | Barcode or model-number scanning | Manual entry completes the core job. |
| Photo upload | Video upload | Photos provide useful context with less storage and review complexity. |
| Status timeline and messages | Real-time chat | Asynchronous updates solve the communication problem. |
| Staff assignment and scheduling note | Route optimization | Dispatch can work before logistics automation. |
| Email notification for important changes | SMS and push notifications | Start with one channel the business already operates. |
The parking lot is important. It tells the builder that omitted features are postponed deliberately, not forgotten and available for an AI assistant to “helpfully” invent at 1:43 a.m.
Step 3: name users and permissions
| Role | Can do | Must never do |
|---|---|---|
| Customer | Manage own profile and appliances; create and view own requests; upload files; read public updates | See another customer, assignment details, or private staff notes |
| Coordinator | View requests; assign technicians; schedule visits; update status; write public or private notes | Change owner-level settings or access unrelated administrative functions |
| Technician | View assigned jobs; add visit notes and photos; recommend status changes | Browse unassigned customer records or manage users |
| Administrator | Manage users, roles, service categories, and all requests; review audit events | Operate without strong sign-in controls and logged sensitive actions |
Permissions belong in the specification because “we’ll add security later” usually means “we’ll discover the data model was built around the wrong assumptions.” Use the AI app security checklist to test these boundaries before launch.
Step 4: model the information
Write down the nouns the app must remember. Each record needs an owner, relationships, and lifecycle. For this portal:
| Record | Important fields | Relationships and rules |
|---|---|---|
| User | Name, verified email, role, active status | One customer owns appliances and requests; role changes are restricted and logged. |
| Appliance | Type, brand, model, serial number, nickname | Belongs to one customer; may have many repair requests. |
| Repair request | Problem summary, description, status, urgency, created date | Belongs to customer and appliance; may be assigned to one technician. |
| Attachment | File reference, type, size, uploader, created date | Belongs to a request; allowed file types and sizes are enforced. |
| Update | Message, visibility, author, timestamp | Belongs to a request; visibility is public-to-customer or staff-only. |
| Appointment | Start window, end window, address, status | Belongs to a request; customers see confirmed windows, not internal scheduling notes. |
| Audit event | Actor, action, record, timestamp | Captures sensitive administrative and assignment changes. |
Avoid a single “notes” field that tries to be customer message, technician report, scheduling scratchpad, and historical truth. Those jobs have different audiences and retention needs.
Step 5: define the request state machine
A status is not a decorative label. It controls what happens next. Our repair request uses this path:
- Draft: customer can edit or delete before submitting.
- Submitted: customer can add information but cannot silently rewrite the original request.
- Needs information: staff asks a visible question; customer receives a notification.
- Ready to schedule: staff confirmed enough detail to plan a visit.
- Scheduled: appointment window is visible to customer and technician.
- In progress: work has begun; staff may add private operational notes.
- Completed: completion summary is visible; further changes require reopening.
- Canceled: reason and actor are recorded; destructive deletion is avoided.
Specify allowed transitions. A customer may cancel before “in progress,” but cannot mark their own job complete. A technician can recommend completion; a coordinator confirms it. If a transition sends email, say so explicitly.
Step 6: describe screens as jobs
- Customer dashboard: see active requests, their statuses, the next action, and a prominent “new request” button.
- New request: choose or add an appliance, describe the problem, upload photos, review, and submit.
- Request detail: see status history, appointment, public updates, attachments, and permitted actions.
- Staff queue: filter by status, assignment, age, and urgency; see which request needs attention.
- Staff request view: manage assignment, status, appointment, public updates, and clearly separated private notes.
- Administration: manage active users and roles, service categories, and audit history.
“Modern dashboard” is visual direction, not a screen requirement. “The coordinator can identify every unassigned request older than 24 hours” is testable.
Step 7: include empty, error, and awkward states
| Situation | Expected behavior |
|---|---|
| New customer has no requests | Explain what the portal does and offer one clear create-request action. |
| Photo upload fails | Keep entered form data, identify the failed file, and allow retry or removal. |
| Session expires while editing | Preserve a safe draft where possible, require sign-in, and return the user to their work. |
| Customer opens another customer’s URL | Return a non-revealing forbidden or not-found state; log the attempt as appropriate. |
| Email provider is unavailable | Save the business action, flag notification failure for staff, and retry safely. |
| Two staff members update status | Prevent or clearly resolve conflicting writes; preserve an audit trail. |
Step 8: turn requirements into acceptance criteria
Acceptance criteria say how a human will decide the feature works. Use observable language:
- Given a signed-in customer with one appliance, when they submit a valid request with two JPG images under the file limit, then the request appears as “Submitted” on their dashboard and staff can see it in the queue.
- Given Customer A, when they request Customer B’s request URL or API record, then the server denies access and reveals no customer data.
- Given a coordinator writing a staff-only note, when the customer reloads the request, then the note and its attachment are absent from the customer response.
- Given a failed notification service, when staff changes a status, then the status is saved once, the notification is marked failed, and staff can see the retry state.
- Given an administrator who deactivates a staff account, when that staff member makes another request using an existing session, then access is denied.
The final build prompt
Your prompt can now reference the specification instead of cramming every decision into a breathless paragraph:
Build the first release of a responsive appliance-repair customer portal using the attached product specification. Implement customer, coordinator, technician, and administrator roles with server-enforced permissions. Start with authentication, the defined data model, customer request flow, staff queue, request detail views, status transitions, and all listed empty/error states. Use accessible forms and clear status language. Do not add parked features. Before styling polish, demonstrate the acceptance criteria with separate test accounts and seed data.
That prompt is shorter because the thinking is elsewhere. It also gives you a way to reject plausible-looking work that violates permissions or skips failure states.
A practical launch plan
- Prototype: use fake data to prove the complete workflow and permissions.
- Internal trial: have coordinators process scripted cases, including failures.
- Pilot: invite five to ten known customers; provide a support path and observe where they stall.
- Readiness review: test security, accessibility, backups, alerts, privacy, and support ownership.
- Limited launch: monitor completion rate, support requests, errors, and notification failures.
- Next release: choose improvements from observed friction, not from the parking lot’s loudest shiny object.
When comparing tools for this specification, use the 25-point AI app-builder scorecard. If you are still choosing an implementation shape, our native vs cross-platform vs web guide helps match the product to its users and constraints.
Editorial disclosure: App9.co is owned by AccelerMedia LLC, which operates App9 Builder. This worked example is tool-independent and intentionally includes the product and security decisions any builder still needs a human to make.