A tool from a prompt

1. Three editors, one untrusted sheet

Three colleagues share a sheet of invented sample records or internal requests. On Monday, one person sorts a single column and separates labels from statuses. On Tuesday, another overwrites a row. By Wednesday, nobody knows which view is current. Your team needs one place where an approved user can add, list, and find an item, not a production software project.

An app builder quickly produces a polished preview. That does not prove records survive refresh, a second user sees the same state, or data can leave the platform. A sharing mistake could expose the prototype beyond the test group. Continue your chosen app from T06-L01, or choose a small app task a colleague needs. Build one useful shared slice with safe prototype data, restrict access appropriately, and test one observable change at a time. The Base44 tracker below is an optional concrete route.

2. After this you can

• Describe a small app through its screens, fields, actions, and exclusions.
• Build a list, add, search, and shared-view workflow from a sequence of short prompts.
• Check persistence and sharing after each generated change.
• Identify the interface, storage, authentication, hosting, export, and account boundaries you actually received.
• Stop at the point where real data, stronger access control, or operational ownership requires IT or a development team.

3. Prerequisites

• Your chosen app idea or prototype from T06-L01; T01-L03 · The simplest thing that works is optional background.
• An approved builder with the storage, sharing, and export capabilities your bounded prototype needs. The worked route uses Base44's built-in entity store.
• A disposable approved project. For the Base44 route, use an account with Private visibility; use Workspace only if every member is explicitly approved for this prototype.
• Separate browser profiles for an approved ordinary app user and an unapproved test account when testing a restricted shared app. In Base44 the colleague receives User, not creator privileges.
• About 90 minutes for the independent exercise.

Use invented records or permitted public content appropriate to your chosen app; keep personal, confidential, regulated, and unpublished data out of this disposable prototype. In the tracker route, the colleague's approved sign-in address is for access only, never TrackerItems. Do not add credentials, external connections, messaging, or project-editor access merely to finish. If a restricted app cannot exclude unapproved users, stop rather than substitute a public link.

4. The idea in one page

Describe what people see and change

Reduce the builder's guesswork by describing four things:

1. Screens: name each view and what appears there.
2. Data: name every field, allowed value, and synthetic starting record.
3. Actions: say what a person can add, view, search, edit, or delete.
4. Exclusions: say what must not be added, connected, collected, or sent.

For the optional tracker, one screen is enough. It contains a heading, a permanent synthetic-data notice, an add form, a search box, and a table. Its records need a stable ID, short label, category, status, owner label, and created date. Users may add and search; they may not edit, delete, upload files, send messages, or call another service. For your app, choose only the screens, fields, and actions needed for the colleague's task, and write its allowed/denied action table before building. Do not add tracker fields to a project that does not need them.

Change one observable behaviour at a time

The worked path uses Base44. Build and check, in order: static screen, built-in entity persistence, search, app access, entity permissions, and separate-session sharing. With another approved builder, follow the same sequence for your app's actual actions using its documented controls; Base44 menu names and permission rules are not universal. Repair a failing step before adding another.

This is a Level 2 Power user build: the blast radius is your team. A wrong row, exposed form, or accidentally broad link can mislead every colleague in the test group, but nobody should yet depend on the prototype for operations. Keep the test small and synthetic. If colleagues begin relying on it, stop and move to the Level 3 design, ownership, and role work.

Inventory what the builder supplied

The result still contains several separate parts:

Inspect project settings, Dashboard -> Data, Permissions, usage, and export. An entity row surviving refresh proves persistence; a preview array does not. An unlisted link is not private. Check the controls shown in your account because plans and availability change.

The free or included tier ends when a current account limit blocks generation, persistence, publishing, sharing, export, or expected use. Stop there; do not enter payment details, begin a trial, switch ownership, or remove a safety boundary to finish.

This supervised prototype's single User role is not a designed identity system. Hand it to IT or a development team before adding real or sensitive data, multiple roles, confidential access, uploads, external APIs, notifications, destructive actions, backups, audit requirements, a custom domain, or team dependency. A hidden or disabled control is not access control.

5. The worked example: a Base44 tracker with a tested boundary

The reproducible build below is the Lab version in Base44. The Company version uses the same entity, permissions, and tests; only its labels and synthetic values change.

Lab framing: a synthetic sample tracker

Start a disposable Base44 project and send this first prompt:

Create the first screen of a small tool named Northstar Synthetic Sample Tracker.
Use one responsive page with:
- a visible notice: "Synthetic prototype. Enter no real sample or person data."
- an add-sample form
- one search box
- one table listing all samples

Use these fields only: item_id, item_label, category, status, owner_label,
created_date. Status must be Received, Checking, or Closed.

For now use three local synthetic records. Add no custom login or role system,
uploads, analytics, notifications, external APIs, integrations, secrets, edit,
delete, or publishing. I will configure platform access separately.
Explain what files, storage, and services you created.

Check the preview at desktop and narrow mobile width. Confirm the warning remains visible, the form has exactly six fields, the status choices are constrained, and the table shows three clearly fictional rows. Ask the builder to remove anything extra before continuing.

Now replace the local records with one Base44 entity as a separate change:

Create one Base44 entity named TrackerItems in this project's built-in data store.
Move the three synthetic rows into it and make the table and form read and create
TrackerItems records. Make all six fields required. Constrain status to Received,
Checking, or Closed. Add no other entity, authentication, service, file import,
external API, integration, edit, delete, notification, or new field. Explain the
entity calls used by the screen and where I can inspect and export its rows.

Add this record through the form, refresh, and confirm that it remains:

item_id: SYN-S-104
item_label: Cedar practice tube
category: Buffer demo
status: Received
owner_label: Demo Bench A
created_date: 2026-09-04

Open Dashboard -> Data -> TrackerItems. There should be exactly four rows, six declared business fields, and no unknown entity or real record. Refresh the creator preview and find SYN-S-104; the colleague session comes after access is configured. If the row disappears after refresh or is absent from the dashboard, the screen is not using the requested built-in entity. Repair that before adding search.

Request search as the third change:

Make the one search box filter the shared table by partial item_id or item_label,
case-insensitively. When nothing matches, show "No synthetic records found" and
keep the add form available. Do not change storage, fields, status values, or
permissions.

Search for 104, cedar, CEDAR, and missing. Clear the query and confirm all records return. Recheck the add form after search; a generated search change must not silently remove validation or persistence.

Company framing: a synthetic internal request tracker

If the company framing fits, use it instead of the Lab labels; do not build a second project. Name it Harborlight Synthetic Request Tracker, warn against real customer or employee data, call the form Add request, and use statuses New, Reviewing, and Closed. Keep the six-field TrackerItems entity and every exclusion. Add:

item_id: SYN-R-208
item_label: Replace practice-room marker
category: Facilities demo
status: New
owner_label: Demo Operations
created_date: 2026-09-04

Test search with 208, marker, MARKER, and missing, then clear it. Storage and permissions remain identical to the Lab version.

Set the app-access and entity boundaries

In Dashboard -> Overview, choose Private visibility and require sign-in. Individually invite the approved colleague, then give them the live-app User role only; do not make them an Admin or collaborator. Base44 documents that app users can use the live app but cannot open the editor or dashboard.

Use Workspace only as a documented exception: inspect the complete member list and confirm that every workspace member is explicitly approved for this prototype. Membership alone is not approval. If one member is unapproved, use Private. If neither route passes, stop. Never use Public, which Base44 defines as open to anyone on the internet.

Next open Dashboard -> Data -> TrackerItems -> Permissions -> Edit. Configure two User Property Check rules—one where User Role is User, one where it is Admin—for Read and Create only. Grant no Update or Delete rule. The owner may be an Admin; the colleague must remain a User.

Save, reopen Permissions, and inspect all four entity actions plus Generated JSON (Preview). There must be no All Users rule: Base44 documents that All Users includes people who have not signed in. There must be no rule granting Update or Delete. Required fields, constrained statuses, a SYN- ID check, and the permanent warning remain input safeguards, not substitutes for access control. Real, confidential, regulated, or operational data still requires a different design and an IT handoff.

Prove the permissions with direct entity operations

Do not infer denial from absent edit and delete buttons. Before the colleague test, ask Base44 to add a temporary, clearly visible Boundary test panel to the page:

Add a visible temporary panel named Boundary test. It must call the same Base44
TrackerItems entity client used by the app, not local state and not an external
API. Give it four explicit test actions: Read all; Create the fixed synthetic row
SYN-S-BOUNDARY / Boundary test tube / Buffer demo / Received / Demo Bench B /
2026-09-04; Update that created row's status to Closed; and Delete that row.
Show each operation, target ID, success or authorization error, and then re-read
the row. Do not change entity permissions, add credentials, or hide failed calls.

Publish the test version. Sign in as the colleague's ordinary app User in a separate browser profile, run the four actions, and inspect Base44's Activity Monitor or browser network activity so the result is from an entity request rather than a message painted by the page.

For the Company version, use SYN-R-BOUNDARY, Boundary marker request, Facilities demo, New, and Demo Operations; the expected permissions are identical. A duplicate-ID validation error is not proof that Create is allowed, and a missing row is not a valid Update/Delete target.

Run two negative access tests. In one browser profile, sign in to an unapproved Base44 account that is neither invited nor a workspace member; open the published URL and confirm it is blocked before any record, form, or Boundary test action appears. In a signed-out private window, require the same result. A sign-in screen proves only that anonymous access is gated, not that a signed-in stranger is denied. If either test fails, unpublish, inspect visibility, invitations, workspace members, and permissions, then repeat all checks in fresh sessions.

After the pass, remove the Boundary test panel, republish, and verify that the permissions matrix has not changed. Use the project owner's Dashboard -> Data controls to remove the boundary-test row if policy requires cleanup; that editor action is outside the app User's boundary. The direct authorization failures—not hidden controls—show that Update and Delete are denied.

Publish only the tested slice

Before the final publish, inspect the project's data, integrations, secrets, sharing, and export settings. Expected state: one TrackerItems entity containing only the declared synthetic rows; Private app access, unless the recorded Workspace exception confirms every member is explicitly approved; User-role and Admin-role Read/Create rules; denied Update and Delete; no All Users rule; no secret; no external connection; no custom identity feature; no upload; no message action. Note whether code export and data export are available and who owns the Base44 account. If portability is absent, treat the project as disposable and do not let it become a relied-on system.

Publish only for the approved test and assessment period. Ask the colleague to open the URL in a separate browser profile, sign in as the approved app User, add one new synthetic row with a unique SYN-TEST ID, refresh, search for that ID, and read the status back to you. The task is real because another person is using the workflow; its content remains synthetic. Re-run both negative checks: the signed-in unapproved account and the signed-out private window must reveal neither the list nor the form.

If the URL admits an unapproved user or exposes project editing controls, account details, unknown records, or broader workspace content, withdraw it immediately, correct the problem, repeat every sharing and permission test, and submit only the corrected live URL. Otherwise, keep the tested URL and access configuration unchanged through exit submission and assessment. After it has been assessed, revoke the colleague's test access and retain or delete the prototype according to your organisation's test-data and account policy.

6. What goes wrong

The screen is polished but the specification is vague

Symptom: cards have inconsistent fields, no stable ID, and several features arrive together.

Fix: name the screen, fields, status values, actions, and synthetic rows. Add view, entity persistence, search, and permissions separately; test after each.

The preview is mistaken for shared storage

Symptom: your row survives while the page stays open but disappears after refresh or never appears for the colleague.

Fix: find the unique ID in TrackerItems, refresh, and test separately. Browser state is not a shared tracker.

There is no usable export

Symptom: the team starts depending on the tool before anyone checks whether code and records can leave the builder.

Fix: export the useful work and reopen it outside the builder. Check that records, text, or other outputs remain intelligible and complete. Inspect code export separately; a source archive is not proof that the app can run elsewhere. If useful work cannot be recovered, label that limitation and do not create a team dependency.

Hidden controls are mistaken for authorization

Symptom: nobody tests Update or Delete because the page has no buttons.

Fix: run the visible direct-operation panel as an ordinary app User. Require authorization failures and an unchanged row before removing the panel; separately require the signed-out access gate.

A gated prototype is accidentally made public

Symptom: an unapproved or signed-out visitor can open the list or add a row.

Fix: unpublish, restore Private visibility (or verify that every workspace member is explicitly approved), remove every All Users entity rule, and repeat the ordinary-User checks plus both signed-in-unapproved and signed-out negative tests.

Real data enters the prototype

Symptom: someone pastes an actual sample identifier, customer request, employee name, or confidential note because the form looks internal.

Fix: remove access, follow the incident process, and delete through the approved route. Revisit T12-L01 · What you may and may not paste into AI at work.

You publish without an independent user

Symptom: the tool works only in the creator's logged-in browser, while the approved colleague cannot pass the intended account gate or sees a blank list, broken mobile form, or stale state.

Fix: have the approved colleague sign in as an app User, open the URL, add a unique synthetic row, refresh, search, and report the result. Confirm separately that both a signed-in unapproved user and a signed-out visitor are blocked.

7. Do it yourself: a usable small tool in 90 minutes

Minutes 0-10: choose one colleague task in your own app. Define its smallest useful screen/action slice, fields if needed, allowed/denied actions, exclusions, and approved publication method. The optional Lab/Company tracker uses six fields and add/list/search; your app need not.

Minutes 10-25: adapt the first prompt to the chosen slice. Check desktop, narrow screens, readable labels, and keyboard use; remove extras and keep the prototype/data notice visible.

Minutes 25-40: add the persistence or output behaviour your task needs. For the tracker, create TrackerItems, add invented records, refresh, and confirm schema and rows in Dashboard. Inspect equivalent stored state or output in your chosen builder.

Minutes 40-50: add the next necessary interaction. For search, test case, no match, clear, and form persistence. For another action, state and check its normal, empty, and invalid-input behaviour.

Minutes 50-60: configure the chosen app's access and stored-data permissions. For the tracker, use Private access and User/Admin Read/Create rules with no Update/Delete or All Users grant; use Workspace only after confirming every member is approved. Reopen and inspect the actual rules.

Minutes 60-75: directly test the relevant allowed and denied operations as an ordinary user; hidden controls do not prove denial. The Base44 tracker uses the visible Boundary test panel above. For a restricted app, confirm that both a signed-in unapproved account and a signed-out visitor are blocked.

Minutes 75-85: remove temporary test controls, recheck permissions, and have a colleague complete the intended task without creator privileges or coaching. For the tracker, they add, refresh, and find a unique synthetic row.

Minutes 85-90: inspect data, secrets, integrations, ownership, and the live page. Export the useful work and reopen it in an ordinary editor or reader outside the builder. Check an added record or generated output against the app, including identifiers and values where relevant. Record what is recoverable and what is not. Keep the tested URL and access configuration stable through the agreed assessment period, then apply the approved retention policy.

8. Exit check

Deliver one bounded app handoff: the prototype URL, its intended colleague task, and the usable export recovered from that task. Include a short note on ownership, access, and remaining prototype limits.

It passes when a colleague has completed the intended task in a separate session without creator privileges or coaching, relevant state survives refresh, and useful work has been exported and reopened outside the builder. The tracker must pass the full Read/Create/denied-Update/Delete checks above; a different app must pass its declared action and data-access checks. Restricted apps must block both signed-in unapproved and signed-out visitors. Base44 Workspace sharing is acceptable only when every member is explicitly approved. The prototype must expose no unapproved data or builder controls. Keep the tested access configuration stable through assessment. Team dependency, rather than merely writing code, is the transition to L03.

9. Rule to remember

Describe the screens and the data. The rest is the tool's job.

10. Further reading & tools

• Taught: T01-L03 · The simplest thing that works - decides when a small app is more appropriate than a document, chat, or fixed automation.
• Taught: T12-L01 · What you may and may not paste into AI at work - sets the data boundary before a prototype receives any input.
• Taught: Next step: T06-L03 · An app your colleagues actually use - moves from a small supervised team prototype to an app with designed roles, failure states, concurrent-use decisions, and ownership.
• Taught: AI app builders - distinguishes a synthetic prototype from a production app and identifies the later security and operating review.
• Taught: Base44 - shows how to inspect entity data, permissions, API scope, and export controls.
• Catalogued: Base44 data documentation (opens in a new tab) - primary documentation for current entity storage, import, and export behaviour.
• Catalogued: Base44 security settings (opens in a new tab) - primary documentation for current entity permission controls.
• Catalogued: Base44 app access (opens in a new tab) - primary documentation for visibility, app-user invitations, roles, and the editor boundary.
• Catalogued: Tools index - compare current app builders, then verify approval, plan limits, ownership, export, and data handling in primary documentation.