A tool from a prompt

2. 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. You will build the smallest synthetic tracker, gate it to approved users, and test one observable change at a time.

3. 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.

4. Prerequisites

• T01-L03 · The simplest thing that works.
• Base44, approved by your lab or company, with permission to use its built-in entity store and publish a disposable synthetic prototype.
• A disposable approved project with an account that offers Private visibility. Use Workspace visibility only if every workspace member is explicitly approved to use this prototype.
• Separate browser profiles for one approved colleague who can sign in as an app User and one signed-in but unapproved test account that has not been invited to the app or workspace.
• About 90 minutes for the independent exercise.

Use only invented tracker records. The colleague's approved sign-in address is used only for app access; never place it in TrackerItems. Do not upload a sheet, connect a database, add a key, authorize messaging, invite a collaborator or project editor, or paste real, confidential, regulated, or unpublished data. If your account cannot restrict the live app to approved signed-in users, stop rather than substitute a public link.

5. 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 this tool, one screen is enough. It contains a heading, a permanent synthetic-data notice, an add form, a search box, and a table. The 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.

Change one observable behaviour at a time

This path uses Base44 only. Build and check, in order: static screen, built-in entity persistence, search, app access, entity permissions, and separate-session sharing. 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.

6. 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.

7. 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: inspect code and data export. If incomplete, label the prototype disposable.

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.

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

Minutes 0-10: choose Lab or Company. Define the user, one screen, six fields, statuses, add/list/search actions, exclusions, and approved publication method.

Minutes 10-25: send the first prompt. Check desktop and mobile; remove extras and keep the warning visible.

Minutes 25-40: create TrackerItems, add invented records, refresh, and confirm schema and rows in Dashboard.

Minutes 40-50: add search; test case, no match, clear, and form persistence.

Minutes 50-60: configure Private app access and User/Admin Read/Create rules with no Update/Delete or All Users grant. Use Workspace only after confirming every member is explicitly approved. Reopen and inspect all rules.

Minutes 60-75: add the visible Boundary test panel. As the ordinary app User, directly test Read/Create/Update/Delete and verify the entity after each; confirm that a signed-in unapproved account and a signed-out visitor are both blocked.

Minutes 75-85: remove the panel, recheck permissions, and have a colleague add, refresh, and find a unique synthetic row without coaching.

Minutes 85-90: inspect data, secrets, integrations, export, ownership, and the live page. Keep the tested URL live and unchanged through submission and assessment; apply the approved retention policy afterward.

9. Exit check

Deliver exactly one artifact: one access-controlled live URL that an approved colleague opens and uses to add, refresh, and find one synthetic record for a real tracking task.

It passes when the colleague can sign in through Private sharing as an app User without creator privileges, see the synthetic-data warning, add a uniquely identified synthetic row, refresh without losing it, search by ID or label, and read its status from the shared view. Workspace sharing passes only when every workspace member is explicitly approved. Both a signed-in unapproved account and a signed-out private window must be blocked before the list or form appears. Keep that tested URL and its access configuration unchanged from submission until assessment is complete. Submit no screenshot, export, test record, prompt log, or second deliverable. The URL fails if it contains real data, admits an unapproved user, exposes builder editing controls, depends on coaching, or cannot be opened in the colleague's separate session.

10. Rule to remember

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

11. 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.