Put journeys inside one Lovable project when they form a coherent app with an accountable owner. Do not group unrelated ideas merely because the same person requested them or they share a visual style.
Start with the documented container
Lovable describes a project as one app. Each project lives in a workspace and has a single project owner. Its contents include chat, preview, code, version history, and settings; edits are saved automatically to version history.
That establishes the organisational container. It does not, by itself, prescribe database design, deployment architecture, or how many user roles an app should contain. Treat the boundary exercise below as editorial planning advice rather than a platform restriction.
Draw an app-boundary canvas
Create five labelled blocks in a document:
- Purpose: The single outcome this app exists to support.
- Journeys: What each fictional user starts with and finishes with.
- Shared information: Which records those journeys need in common.
- Ownership: Who accepts changes and resolves conflicting requirements.
- Exclusions: Requests deliberately left outside this app.
Connect journeys only where they share meaningful information or a common outcome. “Both need a login” is not enough justification by itself. Conversely, different screens do not automatically mean different apps.
Add one ownership question: if two stakeholders disagree about a release, who makes the final decision? A single documented project owner should not conceal unresolved responsibilities within the team.
Evaluate a hypothetical training centre
Imagine a Jaipur training centre planning a demonstration with three invented courses, eight fictional enrolments, and two user journeys: applicants request a seat; a coordinator reviews requests.
Those journeys share course availability and enrolment status. A reasonable proposed boundary is “course enquiry and review”. Evaluate it by tracing one application from submission to a visible coordinator decision.
Now add a request for staff expense reimbursement. It has a different outcome and decision-maker. Put it in the exclusions block pending separate discovery rather than assuming it belongs in the same project.
This is a planning example, not a claim that Lovable implements these journeys automatically.
Decide what to defer
Stop if you cannot state the app's purpose in one sentence or identify who accepts changes. Next, review every proposed journey against that purpose and move uncertain requests into a separate backlog. Splitting the backlog need not mean immediately creating another project.
When comparing access, use the coding catalog to check access format and save offer terms before buying. Marketplace account/code/token offers are not proof of official subscription equivalence or project ownership arrangements.
Sources and scope
Source material checked 29 October 2026; features/policies may change. Lovable project overview establishes project contents, ownership, workspace placement, and automatic version history. The canvas and boundary decisions are editorial advice. Provider documentation does not establish marketplace offer terms.