Prototype an app with AI

Can I use Lyre to prototype an app?

Yes. Use a coding agent in Lyre to make a small web prototype in a folder on your computer, review its changes, and interact with the running app. Then use Share app to invite someone to try that selected app with App-only access. The host computer runs the agent and app; keep it awake, online and running Lyre while another device uses the prototype.

Prepare a small, testable idea

Choose one action you can check: add an item, calculate an estimate or move a request through a status. You can test the usefulness of that workflow before investing in authentication, payments or production integrations.

Pick a useful first workflow

These are example ideas, not customer stories or completed Lyre templates. Keep the first version narrow enough to try yourself.

Real business use will need its own decisions about data storage, permissions, backups and operations. A working prototype helps you ask better questions about those requirements.

Open a project and ask for one change

1. Add the folder

   Choose Add project, select your empty folder and open a workspace. Check the selected computer and directory before sending work. The first-project guide covers this entry point; existing projects have a separate preparation path.

2. Choose the agent and model

   Check the available provider and account in the conversation composer. Claude Code, Codex and other supported agent software keep their own setup, models and permission controls. Use coding-agent connections and task modes for those choices; a task mode does not grant command access.

3. Review a plan before implementation

   Describe the user, one useful action and the result you will test. Ask the agent to identify setup requirements before editing. Read the proposed files, commands and any provider approval request before proceeding.

Example: a handover checklist

Adapt this example request to your own idea. It is a proposed task, not evidence of a finished app.

Plan a small web prototype for a shift handover checklist.
Use fictional sample tasks. A person should be able to add a task,
mark it complete, and filter to unfinished tasks on a narrow screen.
Explain the proposed files, dependencies and start command first.
Do not change files or connect external services yet.

After reviewing the plan, request the agreed implementation:

Implement only the agreed checklist workflow in this project.
Keep unrelated work intact. Use sample data and explain where it is
stored and whether it survives refresh. Run the relevant checks.
Report changed files, actual results and anything still unverified.

Review the edit and try the prototype

1. Inspect the actual changes

   Open Changes and read the diff. Check the dependencies and whether the code sends data to any service. Follow file and diff review before committing. An agent saying it finished is not a test result.

2. Prepare and open the app

   Install its dependencies and configure the documented start command, then choose Open app. Use the recipe for its web framework and project startup settings. A process running is separate from the preview responding.

3. Perform the original task

   Add a task, complete it, filter the list and refresh. Check empty and invalid input as well as the happy path. If you need phone feedback, pair a compatible client and repeat those interactions there. Inspect real check output and save a working checkpoint before expanding the idea.

Invite someone to try one workflow

Use the built-in Share app action after verifying the selected prototype. Choose the Viewer option when available and confirm App-only access before creating an invitation. Share only sample data and give the tester a specific task, such as finding an unfinished handover item.

Follow invitation setup and the tester checklist. App-only access is limited to the selected app; it does not grant source, agents, terminals or host settings. The host's sharing policy must permit the action. Free includes remote live app previews within the host account's application relay allowance; see plan limits.

The five-minute invitation redemption window is not the lifetime of the granted access. When feedback ends, use Manage devices and apps to remove the tester's access and check they cannot reopen the prototype. Stop sharing explains the controls. Stop the app separately when you want its process to end.

If the prototype or test session fails

The agent cannot start

Check the selected host, project grant, provider readiness and quota in provider recovery. Do not solve a denied project request by granting unrelated access.

The app does not open

Read the start command output and check dependencies, listening port and backend routing. Preview recovery and project checks separate a running process from a working app.

The tester loses the connection

Check host sleep, power, connectivity and the tester’s current grant. Inspect the existing app before starting a second copy. Follow offline recovery.

Feedback calls for a bigger feature

Keep the working version and request one bounded follow-up. Review data, authorization and deployment requirements before replacing sample behavior with a live service.

What this prototype establishes

This workflow establishes an interactive web prototype only when you have actually run and tested it. It does not establish production readiness, store acceptance, security review, scale or native-device support. Native builds need their own target, tools and platform checks. A shared preview remains dependent on its host; publishing and deployment are separate tasks.

Agent and App have independent lifecycles. Stopping one does not prove the other stopped. Keep provider choices and approval controls with their existing owners, and review what data leaves the host before using cloud models or other services.