Build a Full-Stack Web App with AI
Build a client portal in Layerwise with a clear prompt, saved requests, user sign-in, local testing, and a published release.
Table of contents
A full-stack web app needs a usable interface, a way to save information, and rules for who can access it. An AI app builder can help you implement those pieces, but you still need to define the workflow and test the result.
This guide uses a client request portal as an example. A client signs in, submits a project request, and checks its status. An owner reviews requests and updates their status. You will build it in Layerwise, test it locally, and publish a version people can use.
1. Describe the first version
Install Layerwise, sign in, and select a team. On the team home page, enter your description in Describe the app you want to build..., choose a model available on your team's plan, and send the prompt.
Start with the users, records, and workflow. For this portal, you can use:
Build a client request portal for a small design studio. Clients sign in with
email, submit a request with a title, description, and target date, and view
only their own requests. An owner dashboard shows all requests and lets the
owner change the status between New, In progress, and Completed. Save requests
in the project database. Use a simple, readable layout that works on a phone.Layerwise prepares a local project and opens a conversation with a preview beside it. Your project includes a database and authentication; the portal's request records, ownership checks, and screens still need to be implemented for this workflow.
If you want to begin with an existing interface, browse the app templates instead. The Sales Dashboard template is a starting point for a sales tool, while NoteNest provides a notes workspace. Choose one because its workflow is useful to you, then adapt it.
2. Test a complete request
Wait for setup and the local preview to finish. Sign up as a client, submit a request, and refresh the page. The request should still appear, with the same title, target date, and status.
Open Database in the project sidebar and select Local to inspect the records. This gives you a second way to check that the form saved data rather than only updating the screen.
Then test the owner path: view the request, update its status, and return to the client account to confirm the change appears. Do not assume that hiding the owner dashboard is enough to secure it. Ask for the authorization rules explicitly:
Check request access on the server. A signed-in client may view and change only
their own requests. Only the owner may list all requests or change their status.
Return a clear error for unauthorized access, and verify with two client accounts.Use separate accounts to confirm that one client cannot read another client's request. The authentication guide explains the project's sign-in flows and the Local user-management view. The database guide explains how to inspect records.
3. Make focused changes in the preview
After the first workflow works, request one change at a time. For example:
Add an empty state to the client's request list with a short explanation and a
New request button. Keep the current request form and status labels.Check both an account with no requests and an account with existing requests. Switch the preview to phone width, submit an incomplete form, and read the error message. A useful result lets the client understand what happened and what to do next.
You can also edit the source directly. The project files live on your computer, and the built-in editor or your preferred editor works on the same workspace. See code and GitHub for opening the code and connecting a repository.
If the preview fails, open its console from Project actions. For a failed backend request, use the project's Logs view to inspect the status and messages. Include the failing action and error in your next message so the assistant has something specific to investigate.
4. Publish and test the live app
Once the local paths work, choose Publish in the preview header, then select Publish in the menu. Wait for the release to finish and open the live URL shown there.
Local and Online use separate databases. Publishing applies the project's schema to production; it does not copy your local test records or accounts. Create a test account on the live app and repeat the request workflow there. Check the email sign-in path, record saving after refresh, owner access, and the phone layout.
The publishing guide explains release status. If you want your own hostname, follow custom domains after the published app works.
5. Use evidence for the next change
After sharing the portal, open Analytics to see pageviews, estimated visitors, popular pages, and traffic sources. Use Logs to investigate failed requests. These answer different questions: analytics shows usage, while logs help explain a particular backend failure.
If clients visit the form but report that submission fails, reproduce their action and inspect its request in Logs before changing the interface. If the workflow works but people cannot find it, revise navigation and verify the new path in the preview.
Start with a small workflow you can exercise end to end. For the exact workspace controls, continue with Build and preview. For a new project from scratch, follow the Quick start.