OXVO Builder is the product-creation surface of OXVO. Teams can create a new app, import existing source, or start from a template; use AI Chat to plan and implement bounded changes; inspect the result in Preview, Problems, and Code; add managed backend capabilities when the product needs them; and publish a reviewed revision.
Builder can support a production-ready process, but generation alone does not make an app production-ready. The release becomes credible through clear scope, review, live-environment verification, and evidence from the people who actually use the product.
Start with the right boundary
Choose a starting point that matches what already exists:
Start from a prompt when the product and primary journey are clear.
Import source when a repository is the intended foundation and its dependencies and runtime assumptions can be reviewed.
Use a template when its routes and interaction model are close to the desired app.
Reuse Library prompts, Theme Prompts, or media when the resource is genuinely portable across projects.
Before creating anything, confirm the active workspace. Projects, templates, Library resources, settings, credits, and plan limits are workspace-scoped.
Write the first request around an outcome
AI Chat is most useful when the task is reviewable. A strong request names:
the current problem or new outcome;
the target user;
the behavior that should change;
the routes, components, data, and breakpoints in scope;
the constraints and behavior that must remain unchanged; and
the checks that will prove the result works.
This is more actionable than a broad instruction to make the app better. It also makes approvals and review easier when the change touches files, packages, commands, external tools, or other sensitive operations. Available modes, models, and tools can depend on the workspace plan and settings, so the visible Builder UI remains the source of truth for the current workspace.
Review the user journey, not only the generated component
After each meaningful change, open the route a real user would enter and complete the primary action. Review desktop, tablet, and mobile widths; navigation and forms; keyboard behavior; loading, empty, success, error, and disabled states; text hierarchy; overflow; and integration behavior.
Use Problems to find the first causal build, type, runtime, or preview error. Use Code when structural inspection is needed. When a visual correction is required, select or annotate the specific component and request one repair at a time, including the affected breakpoints and what must remain intact.
A healthy Preview is necessary but not sufficient. Access controls, custom domains, environment values, authentication callbacks, Messenger, Sessions, and external services must be tested against the published app separately.
Add backend behavior only when the product needs real state
Builder Cloud is the managed backend path for hosted Builder apps that need persistent authentication, data, storage, users, or supported backend operations. A form does not automatically require a backend, but a production workflow that must survive across users and sessions does.
Add backend capability incrementally. Finish the frontend journey, enable the required Cloud surface, add one schema or authentication capability, test the normal and failure paths, inspect the resulting data or users, and review usage and ownership before publishing. Do not present browser-only mock state as production authentication or persistence.
Publish as a separate release step
Publishing makes a Builder revision available outside the editing workspace. Before publishing, confirm the correct app and revision, the intended access mode, the primary journey, responsive behavior, backend configuration, sensitive-value handling, and any Messenger or Sessions integration for that environment.
After publishing, open the live URL in a clean browser session. Test the route, access behavior, authentication, forms, connected services, and domain status. A signed-in Builder tab can hide mistakes that a real visitor would encounter. Keep a known-good recovery path and an owner for the release.
How Builder closes the OXVO Loop
A published Builder app can embed OXVO Messenger for customer conversations and install OXVO Sessions for behavior evidence. OXVO Loop connects those signals to the active app so a change can begin with a real user problem rather than an abstract redesign request.
The safest operating pattern is intentionally narrow:
Gather a repeated customer or behavior signal, not one ambiguous report.
State the affected route, user impact, expected behavior, and evidence.
Open the matching project and select the relevant component or route.
Ask for one focused change with constraints and acceptance criteria.
Review Preview and Problems, test the full journey, and publish deliberately.
Compare new Console conversations and Sessions evidence after release.
OXVO Loop does not automatically make every recommendation correct or publish every suggested improvement. Product judgment, permissions, approvals, and release review remain part of the process.
Example: turn observed friction into a controlled change
Imagine that Console conversations repeatedly point to confusion on an onboarding step, while Sessions shows users reaching the same disabled action without an explanatory state. The Builder request can be specific: add an inline explanation and an accessible recovery action on that route, preserve the underlying permission rule, keep the existing mobile layout, and verify the loading, disabled, and success states.
That scope gives Builder something concrete to implement and the team something concrete to test. After the revision is published, Console and Sessions provide the same evidence surfaces for checking whether the original friction continues.
A credible first release is intentionally small
Choose one primary journey, one clear acceptance standard, and only the backend capability the product genuinely requires. Verify the app in Preview, publish the reviewed revision, test it in a clean session, and connect Messenger or Sessions only where the operating team is ready to use the resulting evidence. Builder is most valuable when creation, verification, release, and learning remain part of one controlled workflow.
