> ## Documentation Index > Fetch the complete documentation index at: https://docs.zeus.ttr.gg/llms.txt > Use this file to discover all available pages before exploring further. # Plans MVP > Presentation-ready MVP scope for Zeus's AI-first financial planning experience ## 1. document purpose This document defines the **MVP scope** for Zeus's **Plans** feature. The MVP is intentionally smaller than the full [Plans target-state BRD](/concepts/plans). Its job is to prove the core product loop, communicate product intent, and give stakeholders a concrete view of what the final experience is evolving toward. This MVP should be strong enough to present as a credible proof of concept, while staying narrow enough to build and validate quickly. ## 2. MVP objective The MVP must prove five things: * Zeus can turn monthly income into a recommended plan, not just a static budget. * Users can understand and activate the plan with minimal setup effort. * Users can see how current spending affects goals and safe-to-spend. * Users can use a simple daily safe-to-spend signal to stay aligned with the monthly plan. * Zeus can intervene once the user starts drifting off plan. * The experience hints at the future adaptive planning system without requiring the full target-state feature set. ## 3. target users and MVP assumptions ### Primary MVP users | Segment | Why included in MVP | | ---------------------- | ---------------------------------------------------------------- | | Guided starter | Most likely to benefit from a simple recommendation-driven setup | | Goal-driven stabilizer | Needs a clear monthly plan and basic course correction | ### MVP assumptions * Single user account * Single currency * Stable monthly income or manually entered expected monthly income * One active plan per monthly cycle * One primary savings goal * Existing transaction data is available through synced or manually entered transactions * User confirms fixed expenses during setup instead of relying on full automation ### Explicitly deferred from MVP The **variable-income planner** segment is important for the final product, but it is not part of the initial MVP. Supporting irregular income requires different safety-margin logic, more dynamic pacing, and more edge-case handling than this first version should carry. ## 4. end-to-end MVP journey The MVP should demonstrate this full loop: ```text theme={null} User enters or confirms monthly income | v Zeus recommends a monthly allocation | v User accepts or adjusts the plan | v User sees safe-to-spend, daily guidance, and goal progress during the month | v Zeus warns when spending pace or goal pacing drifts | v User accepts a simple rebalance or keeps current plan | v Month-end summary shows planned vs actual and next-cycle improvement ``` This is the minimum loop required to communicate the target-state direction. ## 5. business requirements The business requirements below are written in a simple **Given / As / When / Then** format so product, design, and engineering can align on expected behavior. ### BR-1 income-triggered plan creation * **Given** the user has entered expected monthly income, fixed expenses, and one savings goal * **As** a user who wants guidance without building a budget manually * **When** I start the planning flow or refresh my monthly plan * **Then** Zeus generates a recommended allocation across fixed expenses, essential spending, goal contribution, and safe-to-spend discretionary money ### BR-2 fast review and activation * **Given** Zeus has generated a recommendation * **As** a user who wants both guidance and control * **When** I review the plan * **Then** I can accept it immediately or adjust the allocation with simple controls and see the impact before activation ### BR-3 visible in-month progress * **Given** I have an active monthly plan * **As** a user trying to stay on track during the month * **When** I open Plans after transactions occur * **Then** I can see remaining safe-to-spend, a daily safe-to-spend guide, goal contribution progress, and whether I am on track, ahead, or at risk ### BR-4 daily reinforcement * **Given** I have an active monthly plan * **As** a user who benefits from frequent reinforcement * **When** I remain within healthy daily spending conditions * **Then** Zeus shows a daily on-track streak that reflects planning discipline rather than app activity ### BR-5 daily transaction reminder * **Given** I may forget to record daily spending * **As** a user who wants my plan status to stay accurate with low effort * **When** my chosen reminder time is reached each day * **Then** Zeus reminds me to input or confirm that day's transactions ### BR-6 early warning and rebalance * **Given** my spending pace or goal pace materially drifts from plan * **As** a user who needs help before the month is lost * **When** Zeus detects a threshold breach * **Then** Zeus shows a clear warning with one recommended corrective action that I can accept or dismiss ### BR-7 month-end reflection * **Given** the monthly cycle is complete * **As** a user building a repeatable habit * **When** I review my plan outcome * **Then** Zeus shows planned versus actual results and suggests one improvement for the next cycle ## 6. MVP feature requirements The MVP should include only the capabilities required to prove the core planning loop. ### 6.1 plan setup and recommendation #### Requirement The system must allow the user to create a monthly plan using: * Expected monthly income * Fixed monthly expenses * One primary savings goal * A simple lifestyle preference or planning mode The system must return a recommendation that includes: * Fixed expenses amount * Essential variable spending amount * Goal contribution amount * Safe-to-spend discretionary amount * A short explanation of why the recommendation is reasonable #### MVP business rule The recommendation should follow this order: 1. Cover fixed expenses first. 2. Reserve a realistic essential spending allowance. 3. Fund one primary goal if money remains. 4. Assign the rest to safe-to-spend discretionary room. #### MVP proof point This proves Zeus can convert financial inputs into an opinionated monthly plan rather than just displaying raw numbers. ### 6.2 plan review and adjustment #### Requirement The user must be able to: * Accept the recommendation in one primary action * Adjust key allocation amounts before activation * See updated goal pace and safe-to-spend after each change #### MVP business rule If user adjustments weaken the plan, the system must show a lightweight warning, but still allow the user to continue. #### MVP proof point This proves the product balances automation with user control, which is central to the final-state design. ### 6.3 active plan dashboard #### Requirement After activation, the user must see a simple plan summary that includes: * Total planned income * Remaining safe-to-spend * Daily safe-to-spend guidance based on remaining discretionary room and remaining days * Goal target for the month * Amount contributed so far * Daily on-track streak * Current plan status: `on track`, `watch`, or `at risk` #### MVP business rule The dashboard must be understandable at a glance and should not require users to inspect categories or raw transactions to know where they stand. #### MVP proof point This proves Plans is a living control layer, not a one-time setup flow. ### 6.4 daily guidance and streak #### Requirement The MVP must translate the monthly plan into a simple daily guide. The system must: * Calculate a daily safe-to-spend number from remaining discretionary room and remaining days in the cycle * Update that number as spending happens * Show a daily on-track streak when the user ends the day within healthy plan conditions #### MVP business rule The daily guide is directional, not a rigid daily budget. It should help users make better day-level decisions without making the experience feel punitive or overly precise. A day should count toward the streak when: * discretionary spending remains within expected pace for that point in the month * goal pacing is not materially behind threshold * there is no unresolved high-risk warning on the active plan #### MVP proof point This proves Zeus can connect a monthly plan to day-to-day behavior in a way that feels actionable and motivating. ### 6.5 daily transaction input reminder #### Requirement The MVP must support one simple daily reminder that prompts the user to log or confirm transactions at a fixed time. The system must: * Allow the user to enable or disable the reminder * Allow the user to set one preferred daily reminder time * Send a reminder to input or confirm that day's transactions * Provide a direct path from the reminder into transaction input or review #### MVP business rule This reminder is operational, not conversational. Its purpose is to improve plan accuracy and keep daily guidance current, not to become a general coaching channel. #### MVP proof point This proves Zeus can support the daily planning loop by helping users keep transaction data current. ### 6.6 basic warning and rebalance prompt #### Requirement The MVP must support at least one basic intervention flow. Recommended triggers for MVP: * Discretionary spending exceeds `110%` of expected pace * The user consumes `80%` of safe-to-spend before `70%` of the month has passed * Goal contribution is projected to finish below `85%` of monthly target When triggered, the system must: * Explain what changed * State why it matters this month * Recommend one corrective action * Allow the user to `accept` or `dismiss` #### MVP business rule The first version should favor clarity over sophistication. One good warning pattern is better than several shallow ones. #### MVP proof point This proves Zeus can behave proactively, which is one of the most important signals of the target state. ### 6.7 month-end summary #### Requirement At the end of the cycle, the user must be able to review: * Planned vs actual discretionary spend * Planned vs actual goal contribution * Whether the plan was completed successfully * One recommended adjustment for the next month #### MVP proof point This closes the loop and demonstrates that Plans can become a recurring habit, not a single-use feature. ## 7. in scope The following items are **in scope** for MVP: * Monthly plan creation for stable-income users * One primary savings goal * Recommended allocation across four buckets: * Fixed expenses * Essential variable spending * Goal contribution * Safe-to-spend discretionary * One-screen review and adjustment before activation * Active plan dashboard with current month status * Daily safe-to-spend guidance * One daily on-track streak tied to planning behavior * One fixed-time daily transaction input reminder * Basic spend pacing and goal pacing logic * One warning and one rebalance recommendation pattern * Month-end summary for plan performance * Plain-language AI explanation for recommendation and warning cards ## 8. out of scope The following items are **out of scope** for MVP: * Variable-income planning logic * Multiple simultaneous goals with prioritization logic * Automatic goal reprioritization * Advanced adaptive learning from repeated accepts or rejects * Transaction-level time-equivalent and opportunity-cost insights * Missions, rewards, points, levels, and complex gamification systems * Daily coaching flows or multiple high-frequency prompt types * Household or shared planning * Tax planning, investment advice, lending, or credit decisions * Human advisor escalation * Full conversational chat interface for planning ## 9. user acceptance criteria The MVP is acceptable for presentation and pilot validation when the following criteria are true. ### End-to-end acceptance criteria * A user can create a monthly plan from input to activation without external explanation. * A user can accept the recommended plan in one primary action. * A user can adjust the plan and understand the trade-off before confirming. * A user can tell, within a few seconds, how much is safe to spend this month, how much is safe to spend today, and whether the goal is on track. * A user can understand why a daily on-track streak increased or broke. * A user can receive one fixed-time daily reminder to input or confirm transactions. * A user receives at least one meaningful warning before month-end when plan drift occurs. * A user can complete the full monthly loop from plan creation to month-end review. ### Feature-level acceptance criteria | Feature | Acceptance criteria | | -------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------ | | Plan recommendation | Recommendation appears immediately after required inputs and shows all four allocation buckets with amount and rationale | | Plan adjustment | User can change at least the goal and discretionary allocation and see updated impact before saving | | Active dashboard | Dashboard shows monthly safe-to-spend, daily safe-to-spend, goal progress, streak state, and current status without requiring navigation to raw transactions | | Daily guidance and streak | Daily guide updates as spending happens and the streak reflects financial behavior rather than app usage | | Daily transaction reminder | User can set one reminder time, receive one daily prompt, and open transaction input or confirmation from that prompt | | Warning prompt | Warning includes current issue, suggested action, and a clear accept or dismiss path | | Month-end summary | Summary shows planned vs actual results and one concrete suggestion for the next cycle | ## 10. how this MVP demonstrates the target state The MVP should not include the full target-state capability set, but it must make the destination obvious. | Target-state intent | How the MVP signals it | | ------------------------------ | ----------------------------------------------------------------------------------------------------------------------- | | AI-first planning | Recommendation is generated by Zeus, not manually assembled by the user | | Adaptive planning | A warning and rebalance flow shows the plan can react to behavior, not stay static | | Goal-linked money decisions | Goal contribution and safe-to-spend are visible in the same plan | | Daily behavioral reinforcement | Daily safe-to-spend and a daily on-track streak connect the monthly plan to everyday choices | | Lightweight habit support | A fixed-time transaction reminder helps users maintain accurate daily tracking without needing a larger coaching system | | Low-friction interaction model | Accept, adjust, and rebalance actions happen through direct UI controls | | Recurring habit loop | Month-end summary suggests that planning becomes a repeated cycle | ## 11. release recommendation This MVP should be presented as a **proof of concept for the Plans operating model**, not as the finished adaptive planning system. If stakeholders can see the following during a demo, the MVP has done its job: * Zeus can create a recommendation that feels useful and opinionated * The user can activate the plan quickly * The product can show current plan health during the month * Zeus can intervene when the user starts drifting * The path from MVP to the full [Plans target-state BRD](/concepts/plans) is clear