Planning an App Before Generating Code

Planning converts an idea into decisions an agent can implement and a human can test. Our product brief will guide the web dashboard, mobile tracker, and API without forcing them to share code.

Product statement

Expense Suite helps an individual manually record income and expenses, understand monthly spending, and compare category spending with simple budgets.

The primary user is an adult tracking personal spending. This educational product is not a bank, accounting system, tax tool, payment service, or source of financial advice.

MVP capabilities

1. Email-and-password account access.
2. Private categories owned by a user.
3. Income and expense transactions with amount, date, category, and optional note.
4. Monthly balance, income, and expense summaries.
5. Category totals and monthly budget progress.
6. Edit and delete flows with useful confirmation and errors.

Out of scope: bank synchronization, receipt scanning, recurring transactions, shared accounts, multiple base currencies, transfers, subscriptions, public profiles, and payments.

User flows

Write flows before screens:

First use: create account → confirm/sign in as configured → see empty dashboard → add first category → add first transaction → see updated summary.

Returning use: sign in → view current month → filter transactions → edit a transaction → see recalculated totals → sign out.

Budget use: choose category and month → set positive limit → view spent amount and percentage → see clear warning when exceeded.

Recovery: invalid form preserves values → expired session returns safely to sign-in → failed request offers retry → delete requires explicit confirmation.

Screen map

The web project uses:

• /login and /signup
• /dashboard
• /transactions
• /categories
• /budgets

The mobile project uses tab routes for Dashboard, Transactions, Budgets, and Settings, plus modal or stack routes for forms. Route names can vary during implementation, but user flows and data rules remain consistent.

Conceptual data model

Transaction

• id: generated identifier
• user_id: authenticated owner
• category_id: owned category
• type: income or expense
• amount_minor: positive integer in minor currency units
• currency: ISO-style currency code chosen for the product
• occurred_on: calendar date
• note: optional limited text
• timestamps

Category includes owner, name, kind, color, and timestamps. Budget includes owner, category, month, positive limit in minor units, and timestamps. A unique rule prevents duplicate budgets for the same category and month.

The database—not a user-submitted field—establishes ownership from authenticated context where possible. Policies ensure users cannot access another user's rows.

Product rules

• Amounts must be positive; type determines whether they count as income or expense.
• Deleting a category used by transactions is blocked or requires deliberate reassignment. We choose blocking for the MVP.
• A transaction can reference only a category owned by the same user and matching its type.
• Monthly reports use the transaction's calendar date and an explicitly documented user/display timezone.
• Empty notes become null or an empty value consistently.
• Totals are derived from transactions, not manually edited summary rows.

Quality requirements

• Keyboard and screen-reader users can complete core flows.
• Color is not the only signal for income, expense, or overspending.
• Loading, empty, error, and success states exist for data screens.
• Sensitive values never enter client bundles, logs, screenshots, or Git.
• A second account cannot read or modify the first account's data.
• Money calculations avoid binary floating-point errors.

Delivery slices

Build vertically instead of creating every screen before behavior:

1. Static shell and sample dashboard.
2. Navigation and reusable UI.
3. Local transaction form and calculations.
4. Supabase schema and policies.
5. Authentication.
6. Persistent transaction flow.
7. Categories and budgets.
8. Tests, accessibility, deployment, and monitoring.

Each slice should leave the project runnable.

Prompt: review the brief

Review this product brief as a product engineer, security reviewer, and complete
beginner's teacher. Do not write code. Find contradictions, missing decisions,
unsafe assumptions, and acceptance criteria that are not observable. Preserve
the MVP boundaries. Recommend only decisions required for implementation, and
present the revised brief in plain English.

After revision, save the agreed brief as PROJECT.md in each project. The brief is a contract: update it deliberately when product behavior changes.

Definition of done for a feature

A feature is done when:

• Acceptance criteria are met.
• Relevant automated checks pass.
• The manual happy path and important failure path are checked.
• Authorization is tested when data is involved.
• Error, loading, and empty states are appropriate.
• Documentation and environment examples are current.
• Git shows only intentional changes.

Completion checklist

• The product statement names one user and problem.
• MVP and out-of-scope lists are explicit.
• Core flows include recovery behavior.
• Records and ownership rules are defined.
• Quality requirements are testable.
• Delivery is split into runnable vertical slices.

Next: Git, GitHub, Backups, Secrets, and Safe AI Coding