Troubleshoot an app build

Start with the visible symptom: what you did, what you expected, and what happened instead. Avoid repeating the same broad prompt; a precise observation gives Ahamo a better place to start.

A build does not start

Read the message beside the prompt box.

Check that the active Workspace has enough credits.
Wait if another build is already running.
Complete the initial planning or design step if it is still open.
If Ahamo asks whether to enable a backend, choose before continuing.

Do not submit duplicates while the first request is still pending.

The preview shows an older version

The Build tab keeps the last successful app visible while another build runs.

Wait for the new build result.
Confirm that it completed successfully.
Refresh the preview once.
Read the result summary to confirm the requested area changed.

If the new round failed, the earlier working version may still be the one shown.

The latest build broke the app

Open the failed round in build history and undo it. Confirm that the earlier version works again before asking for another change.

Then choose Plan:

The last change caused the booking page to fail when opening the confirmation step. The previous round works. Identify the smallest correction and preserve the rest of the booking journey. Do not build yet.

See Review history and undo a build.

A visual edit cannot be applied

Some preview elements cannot be changed safely through direct selection. Keep the element selected if possible, switch to Build, and describe the exact change plus anything that must remain unchanged.

For example:

Reduce the space above this form heading. Keep its text, font size, and the spacing between form fields unchanged.

Saved data is missing

Check four things in order:

The backend is enabled and ready.
Runtime is showing the environment where you performed the action.
The app reported a successful save.
The expected row exists under Runtime → Data.

Development and production have separate data. Publishing an app does not copy ordinary development records into production.

If the row exists but the app cannot display it, test with the intended signed-in user and review that user’s access. If no row exists, choose Plan and ask Ahamo to trace the submit action, validation, and visible error state before changing the data model.

Workspace membership and app sign-in are separate. A person who can edit the app is not automatically an app user.

Use a private browser window to test:

signed-out access;
a permitted app user;
a user who should be denied;
the destination after sign-in and sign-out.

Record the starting page, action, expected destination, visible message, and resulting address. Never share a password, session value, or sign-in link token. See Add sign-up and sign-in.

If private content is publicly visible, stop sharing the live link and unpublish the app while you investigate.

An upload or server-side action fails

Use a harmless test file or fictional input. Confirm the selected environment and read the error shown in the app.

For uploads, note the file type and approximate size. Check that a failed upload is not shown as available.

For server-side behavior, test one valid input and one expected failure. Confirm both the visible result and any saved record. Use Store uploaded files or Add secure server-side behavior for the normal setup path.

Publishing fails

Wait for the current publish attempt to finish or fail before retrying. Note whether the problem appears while reviewing settings, publishing, or opening the finished address.

Retry once only when the message describes a temporary problem. If publishing succeeds but the live app is wrong, open the production address in a private window and repeat the exact journey. Compare it with Build and confirm you published the intended version.

See Publish your app for the complete flow.

The problem appears in one browser

Refresh once in a private window. Then try another supported browser or network if available. Note the browser version, device type, approximate time, and whether you were signed in.

Do not ask users to expose browser storage, share session details, or disable security software. A browser-specific failure does not by itself prove the live app is unavailable.

Prepare a useful report

If the problem remains repeatable, collect:

the Workspace and app;
Build, staging, or production;
browser and device;
approximate time with time zone;
exact action;
expected and actual result;
the smallest safe error message;
whether it happens every time and for which test users.

Use fictional or redacted data. Never include passwords, tokens, cookies, private keys, payment details, full customer records, or complete logs. Hide personal information in screenshots.