Plan an Adalo app with Codex before building the screens

I am building a neighborhood repair app in Adalo. A member reports a broken item and tracks its status. A volunteer may later be assigned. For the first version, plan only request creation, a member's own request list, and request details. Produce a collection table with property types and relationship directions, a screen-by-screen data flow, a read/write access matrix, six fictional sample records, and acceptance checks. Use Adalo terminology. Do not assume you can inspect my account. Identify any decision that depends on whether I use the visual builder or Ada. Save the result as a build brief I can revise.

Make the output concrete enough to review. For example, My Requests reads Requests belonging to the signed-in member; Request Detail receives the selected Request; New Request creates a Request with the member relationship populated. If Codex only produces a feature list, ask it to supply these record-level connections.

Suppose the repair app later allows a volunteer to post several progress notes. Storing only Latest Update on Requests overwrites the previous message. Request Updates preserves history because each update has its own author, date, and parent request. That distinction comes from the product requirement, rather than from a preference for more collections.

Ask Codex to walk through three example records before accepting the schema. Which member owns the request? Which volunteer is assigned? Who wrote the most recent update? If any answer depends on matching a display name, replace that fragile link with an explicit record relationship.

For the visual Adalo builder, use the specification as a checklist while creating collections, choosing relationship directions, adding components, and configuring actions. Keep the real labels in the brief so a later Codex review does not compare two different naming systems.

For an Ada-generated app, its current Database documentation describes schema changes through Ada and access through declared endpoints. Give Ada a narrow slice of the specification, inspect the generated collections and endpoints, and compare their scope with your access matrix. Do not transfer older visual-builder menu instructions into that workflow.

This workflow also works in reverse. Start with an existing app's collection list, relationship settings, screenshots, and action descriptions. Ask Codex to reconstruct the user journey and explain where the same information is duplicated or a screen relies on an unavailable record. Remove private member details from the material first.

The useful deliverable is a short discrepancy list: the brief expects the submitting member to be saved, the actual create action omits it, and the owner filter consequently matches nothing. That is actionable. A generic instruction to improve the database is not enough to guide a builder change.