🤖 Using the New Ada in the Adalo Workspace

Skill level: Beginner

🧭 Before you begin

Before you start, make sure:

• You are signed in to the Adalo workspace with access to an app you can safely edit.
• You know what you want Ada to change. A small, specific request is easier to review than a broad redesign request.
• You have a clear starting point. Open the app, screen, or feature you want to work on before asking Ada for help.
• You are prepared to review the result. Ada can make useful changes quickly, but it does not replace product decisions, testing, or approval from the person responsible for the app.

For a first try, use a development or test app. Do not begin with a request that could remove data, change a production workflow, or alter permissions for real users.

🚶 Walkthrough

1. 🚀 Open Ada from your workspace

1. Sign in to Adalo and open the workspace that contains the app you want to work on.
2. Open the app and go to the screen or feature you want to change.
3. Open Ada from the builder.

Ada uses the app context available in the builder to understand what you are working on. The more specific the selected screen and request, the easier it is to get a useful first result.

2. 💬 Start with one concrete request

Describe the outcome you want in plain language. Include the screen, the user action, and any important rule or limitation.

For example:

On the Bookings screen, add an empty state when there are no upcoming bookings. Explain what the user should do next, and keep the existing navigation unchanged.

Avoid combining unrelated work in the first prompt. Start with one change, confirm that Ada understood it, and then continue with the next change.

3. 🔎 Review Ada’s proposed changes

Before accepting a result, check:

• The correct screen and components were changed.
• The layout still works on the device sizes your app supports.
• Data, filtering, actions, and navigation behave as expected.
• Existing styles, copy, and accessibility details were preserved where they should be.
• Ada did not make an assumption that should be a product decision.

When something is wrong, tell Ada what happened and what should remain unchanged. A correction such as “keep the current button action, but move the button below the empty-state message” is more useful than “that is wrong.”

4. 🧪 Test the result in the app preview

Use the preview to test the complete user path, not only the screen that changed.

Check the normal state, empty state, loading state, and error state when they apply. Test the primary action, back navigation, and any data changes. If the app is responsive, check both mobile and desktop layouts before sharing the result.

5. 🔁 Iterate in small steps

Keep related follow-up prompts together and make one adjustment at a time. Examples:

• “Make the title shorter without changing its meaning.”
• “Use the existing spacing and button style from the Home screen.”
• “Show only records belonging to the signed-in user.”

Ask Ada to explain an unexpected change before accepting it. This gives the team a record of the decision and makes the next prompt more precise.

6. ✅ Share or publish only after review

When the feature works in preview:

1. Ask the app owner or reviewer to check the change.
2. Confirm that the change does not expose private data or change access unexpectedly.
3. Test the published experience separately if the change affects a live app.
4. Publish or share the app only through the normal Adalo release process.

Ada helps create and refine the change. The person responsible for the app remains responsible for approving what reaches users.

🧩 A reliable prompt pattern

Use this format when a request needs more detail:

On [screen or feature], [make this change] when [condition]. Keep [things that must not change]. I will verify [how the result should be tested].

Example:

On the Orders screen, show the customer’s orders newest first when the screen opens. Keep the existing order details action and empty state. I will test with a customer who has three orders and one who has none.

🛑 When to stop and ask a teammate

Pause and get a second review when a request involves authentication, payments, permissions, private data, destructive actions, or a change that affects many screens. These changes need a human decision even when Ada can implement part of the work.