Build and publish your first Atoms app, from your first prompt to a live version you can share.

You do not need to learn every agent, mode, or technical term before you start. The basic workflow is much simpler: tell Atoms what you want, check what it built, make changes, test it, and publish when it is ready.

This guide uses a simple cafe website as an example, but the same loop works for a landing page, dashboard, internal tool, or your own app idea.

These steps cover a signed-in desktop web project. Mobile projects use a separate mobile build and distribution flow.

Before publishing, wait for the current build to finish, make sure you have publishing access, confirm the project is idle, and check that required project resources such as credits or storage are available. If Publish is unavailable, check the project version, access, and resource conditions before retrying. Projects that use data, secrets, emails, AI, payments, or other connected services also need their production checks before sharing.

Describe what you want

Start in the prompt box and describe the result you want in normal language. You do not need to write technical specifications or tell Atoms how to code it.

A useful first prompt usually says what you are building, the main sections or features, the visual direction, and anything that matters on mobile.

If you already found something in App World that is close to what you want, you can also start by remixing that project instead of starting from scratch.

Check the first result

Atoms creates the project and builds a first version. When it is ready, open the App Viewer and look through the result before asking for more changes.

Do a quick pass first. You are not trying to find every tiny issue yet. Check whether Atoms understood the main idea.

• Are the main sections and features there?
• Does the overall layout match what you asked for?
• Do the important buttons, links, filters, or other interactions respond?
• Is anything obviously missing, broken, or different from what you meant?

You can preview the app in both PC and mobile modes, so check the experience on more than one screen size before you move on.

Make changes

Treat the first version as a starting point. Tell the agent what you want to change in plain language, then check the result again.

Small, specific requests are usually easier to review than changing everything at once.

For visual changes, you can edit elements directly in App Viewer or describe the change to the agent. If you have a screenshot, design, file, or other reference you want Atoms to follow, upload it and point the agent to it.

When something breaks: If something is actually broken rather than just different from your preference, use Fix Bug or tell the agent exactly what is wrong and where it happens.

If it still fails: Stop repeating the same request after one focused retry. Record the affected step, what you expected, what happened, what you already tried, and a shareable project link or screenshot. If you are a paid user with an account, billing, or Atoms platform issue, open the Atoms Help Center, choose Atoms Support under Explore resources, and select Contact us. For Free-plan users or ordinary product instructions and troubleshooting, start with the Help Center, Ask Assistant, or the Atoms community.

Test before you publish

Before you send the app to anyone, spend a few minutes using it like a real visitor. A quick test now is much easier than explaining a broken link after you share it.

• Click every important button and link.
• Try the interactive parts, such as filters, forms, menus, or navigation.
• Check both PC and mobile views.
• Look for text that is cut off, overlapping, missing, or hard to read.
• Make sure the main user journey works from start to finish.

If your app depends on stored data or backend actions, test those too. Atoms can use Atoms Cloud or connect with Supabase for capabilities such as data storage, secrets, emails, AI calls, and payments.

Before you publish, remove secrets, passwords, tokens, personal information, and private test data from anything visitors can see. Confirm whether the project should be Public or Private, and test the live link with the intended account. If the app uses real payments, emails, stored data, or connected services, verify those production actions separately before sharing.

Publish

When the preview looks right and the main interactions work, click Publish in the top-right corner of the editor.

Publishing creates a live link whose access depends on the visibility you choose. Public can be opened by link and may appear in Discover. Private is visible only to the owner and may be limited by plan. Select the intended visibility before sharing, and test the link with the intended account.

Publishing is the point where your project becomes something other people can actually open. Keep developing in the project, but always check the live version separately after you publish.

Verify the live app

Open the published link yourself before sharing. Confirm that the selected Public or Private visibility gives the intended audience access; use a private window or the intended account to test it.

• Open the link in a new tab or private window using the account or access context that matches the intended audience.
• Confirm the page loads and shows the version you expected.
• Repeat the most important clicks or interactions.
• Check the page on a phone if mobile visitors matter for your app.

If you find a problem, go back to the project, make the change, test the preview again, and then update the live version.

Update after you make changes

Your app does not stop changing just because you published it once. Keep refining it in the project whenever you need to.

After the first publication, the Publish button becomes Update. Click Update when you want to push new changes to the live version.

After an update, open the published link one more time and verify it. That gives you a simple repeatable loop:

Describe → Check → Change → Test → Publish → Verify → Update

That is the core Atoms workflow. More complex apps may add data, authentication, integrations, custom domains, or multiple agents, but the build loop stays the same.