Start with one person and one job
Choose who the app is for and the task it should help them finish. “A tool for freelance designers to track client projects” gives the builder more direction than “make a business app.” Start with the smallest useful version: one main workflow and the pages it actually needs.
Write down the information the app stores, what a person can change, and what success looks like. A project tracker might need a project name, client, due date, and status. Its first useful workflow is creating a project and moving it through those statuses.
What should an AI app prompt include?
Include the audience, main pages, key actions, and visual preferences. State whether the first version may use clearly labeled sample data. If the app needs accounts or persistent storage, say that explicitly; a screen that looks like a login form is not evidence that authentication works.
Build a project tracker for freelance designers. Include a projects dashboard, a project detail page, and a form to add a project. Each project has a client, deadline, budget, and status. Let me edit and filter projects. Use a clean, responsive layout with blue accents. Label any sample data clearly, and explain what is needed for persistent storage.Open the app builder
Try the app, including the awkward cases
BrainHalf places the conversation alongside a browser preview. Try the main journey from start to finish, then check empty lists, long text, missing fields, and small screens. Ask what happens after a page reload and when a request fails.
A browser preview helps you evaluate the frontend. It does not prove that generated servers, database migrations, payment providers, or email services are running. Test those separately in an environment configured for the app.
- Create an item, edit it, and confirm the change appears in the right place.
- Submit an empty form and check that the error explains how to fix it.
- Use a narrow mobile viewport and check navigation and form controls.
- Reload the app and confirm the intended persistence behavior.
Request one focused change at a time
Describe the current behavior and the result you want. “Keep the project form open when validation fails and show an error below the deadline” is easier to verify than “fix the form.” Review each change before adding another feature.
Use the Code view to inspect the generated files when you need to understand an implementation. Export the source so you can continue in your own development tools or involve a developer for a deeper review.
Publish the tested version and check its public URL
In BrainHalf, use Publish after you have tested the main workflow. Supported static apps can go live directly; managed Workers apps can include a backend, an isolated production database and configured sign-in services. Publish builds and checks a saved source version before activating it. You do not need to export code to use managed publishing.
Open the public URL and test it again. For an app with saved records, check persistence and account permissions. For email, check actual delivery to a controlled recipient. If publishing fails, read the message and use Fix publishing problem when available, then review the repair before publishing again. Edits in your workspace do not replace the live app until you publish.
Reference documentation