Plan a multi-page AI application before you build

Write the journey with sample inputs and expected outputs. ‘Add a book’ becomes ‘Enter a title, save it, return to the list, and see that title once.’ ‘Edit a note’ becomes ‘Change the text, save, reload, and read the new text.’ These examples reveal duplicate saves, stale lists, and missing persistence while giving you a compact test script after generation.

A multi-page application is not simply a homepage plus several destinations. Its pages share state, identity, navigation, and rules about what a visitor can do. Start by writing one complete journey: a visitor understands the tool, signs in, creates a record, finds it again, changes it, and leaves safely. This exposes dependencies that a feature list hides. It also gives you a way to decide whether the first release is actually usable.

Choose one primary job for the first version. A personal reading journal can support adding books and notes without becoming a social network, bookstore, recommendation engine, and subscription service at once. Put later ideas in a separate list. Smaller scope is useful when it creates a complete loop, not when it removes the save action or hides an unfinished route. Every promised part of the first journey should work before adding a second major workflow.

For each route, record its audience, purpose, required data, and main action. A public introduction explains the product; a private list shows the current visitor's records; an edit view changes one record. Identify how someone reaches the route and what happens if they open it directly. Do not rely on a previous page silently preparing essential state. A bookmarked URL and a refresh are normal browser behavior, not unusual edge cases.

State whether you need actual separate pages or a section on one page. In Uvilno's supported multi-page static frontend, each approved route should have real content; an anchor on the homepage is not a substitute for a requested route. Keep navigation labels stable and show the current location. For private routes, define the signed-out destination and whether a visitor can return to the intended task after authentication. Avoid losing their safe unsent input during that transition.

A form's unsent text, a selected filter, and a saved book record are different kinds of state. Temporary interface state can live in the current view. A preference may be browser-local. Private records that should survive across devices need a supported hosted service and authentication. Write down these boundaries before building. Without them, an app can look as though it saved data while merely keeping a JavaScript array until the next refresh.

Describe ownership as well as storage. In a personal app, each visitor reads and edits their own records. Shared workspaces and role-based administration require a different authorization model; do not infer that they exist because the interface has a team selector. Uvilno.db offers typed fields and declared references through a bounded hosted service, with optional transactional create/update/increment/notification rules. It is not arbitrary backend provisioning. If your application needs scheduled processing, cross-organization permissions or custom server logic, identify that as separate development or a supported external service and verify it independently.

A control needs a trigger, a state transition, and a visible result. For a save action, specify validation, pending feedback, successful persistence, and a recoverable failure. For a filter, define which records it affects and what happens when none match. For deletion, decide whether confirmation or undo is appropriate and where focus goes afterward. These small decisions make the difference between an application and a collection of styled components.

Keep actions consistent across routes. If a record changes on an edit page, the list should reflect that change when the visitor returns. If a delete request fails, the record should not vanish permanently from the interface as if it succeeded. Avoid duplicate submissions and stale success messages. Describe these outcomes in ordinary language; you do not need to dictate a particular state-management library to make the expected behavior precise.

A multi-page app needs a stable visual language: navigation, page titles, form fields, primary actions, empty states, and feedback should feel related. Provide a coherent direction and ask the builder to reuse those patterns. A public introduction can be more expressive than a compact record list, but both should belong to the same product. Consistency helps a visitor transfer what they learned on one page to the next.

Specify content density by task. A reading list needs scanable titles, status, and a clear next action; an edit page needs a calm form and visible validation. Avoid asking every route to have a giant hero and a decorative card grid. On phones, check where navigation, filters, and save controls go when space shrinks. Shared components should support the actual task rather than forcing all content into one impressive-looking but inconvenient template.

In Uvilno, Plan mode returns a readable proposal in the conversation. Review its page map, service needs, and intended interactions, then use the explicit approval action when the proposal matches your goal. Planning does not expose private source architecture to a locked project. It is a product discussion that prepares a build. Ask for a revision when the plan invents a service, misses a route, or turns private persistence into a local demonstration.

Approval is tied to the current project, brief, draft revision, and base version. If those change, a new approval may be needed. This protects you from building an old plan against a different project state. Planning involves actual processing and can count toward usage, so use it for meaningful uncertainty. A tiny text change on a finished page usually needs a focused edit rather than a new application-wide planning exercise.

After the build, test every required route directly and through navigation. Reload private and nested pages, use Back and Forward, and try the main journey on a phone. Check the actual expected page content rather than accepting any heading as proof the route exists. A polished platform 404 is still a missing page. Confirm that menus, dialogs, and keyboard focus behave correctly as you move between views.

For data, create a record, reload, edit it, delete it, and repeat with a second account. Test the empty state after deletion and a failed request without losing input. For service dependencies, test consent cancellation and the deployed origin separately from the preview. Record the first failing step with the route, state, action, and visible result. This produces a useful correction request and prevents a broad redesign from hiding the original behavior problem.

Once the first journey works, add a related capability as another complete slice. A status filter is a smaller extension than a public social feed. Describe how the addition changes routes, state, ownership, and failure handling. Preserve a known-good version before the larger change and test the existing main journey afterward. A saved version gives you a recovery point; it does not prove that new changes are safe to publish.

Before export, record hosted dependencies and the service configuration needed on your chosen domain. Source unlock releases the frontend files, not a separately provisioned database or identity system. Keep a release note listing the completed journey and any deliberate limits, such as personal records rather than team collaboration. A small app with honest boundaries is easier to maintain, hand off, and extend than a large interface whose underlying behaviors were never decided.