Organize your Lovable register with one row per app, connecting its purpose, workspace, named owner and operating status. That makes ownership gaps visible before a freelancer leaves or a small team changes responsibilities.
Why the app is the right unit
Lovable documents a project as one app within a workspace, with a single project owner. Its contents include chat, preview, code, version history and settings. A register organised only around conversations therefore misses the app-level responsibility the documentation describes.
As practical editorial advice, keep the register separate from informal task messages. It should answer who is accountable today, not merely who last discussed a feature. Do not assume that a familiar collaborator is the named project owner.
Build a stewardship register
Use these fields for each app:
- App identifier and plain-English purpose.
- Workspace identifier and named project owner.
- Internal business sponsor, if different from the owner.
- Operating status: experimenting, maintained, paused or retirement review.
- Maintainer contact and next review date.
- Approved spending contact and unresolved access questions.
- Location of the handoff index and outstanding decisions.
These statuses are suggested editorial labels, not claimed Lovable interface options. Keep credentials, customer records and private conversations out of the register. Use neutral summaries and references available only to authorised reviewers.
For an Indian team coordinating employees and contractors, record review times in IST and specify whether a spending figure is a budget allocation or an actual invoice amount.
Hypothetical three-app review
Suppose a Pune studio lists three fictional apps: a public event guide, a synthetic inventory demo and an internal training prototype. The guide has a named owner and a review next Monday. The demo has a maintainer but no confirmed owner. The prototype has an owner but no operating status.
Evaluate completeness rather than popularity. The demo fails the ownership check even if it has the most development activity. The prototype needs a status decision before anyone assigns more work. The guide passes only if its owner confirms the register entry.
Decide what can continue
Stop new discretionary work on an app whose owner cannot be confirmed. Next, ask the workspace's appropriate decision-maker to resolve accountability; do not infer transfer procedures from the register.
If access procurement is part of that resolution, check the AI tools catalog for access format and saved terms before buying. Marketplace account, code or token offers are not proof of official subscription equivalence, and purchasing access does not establish project ownership.
Sources and scope
Source material checked 29 October 2026; features/policies may change. Lovable project overview establishes the app-level project, workspace, single owner and documented contents. The register, status labels and review gates are editorial advice, not documented product controls.