I founded MondayCall to solve a problem I experienced firsthand: existing financial tools don't clearly show what's actually available to spend. After validating the concept, I assembled a team of four partners and led the end-to-end design and product strategy. We're currently in development, building the system from the ground up.
People don't fail at saving because they lack discipline. They fail because their financial tools don't clearly show what's actually available after obligations, debt, and recurring payments, or provide ways to save that align with how they actually live.
Design a system that clearly explains what money is actually available at any moment, accounting for upcoming obligations, debt, credit usage, and recurring payments. The goal is to reduce uncertainty and help users make confident decisions.
Enable users to move money toward specific goals through savings projects and automated methods that adapt to their income cycle and lifestyle, without requiring constant manual intervention.
MondayCall is built around the idea of financial periods. Instead of looking at money as a continuous balance, the system organizes cash flow into defined periods based on when money comes in and when obligations are due. This approach makes future commitments visible and helps users understand the impact of today’s decisions on the rest of the period.
In MondayCall, available money isn't your total balance or what you spent during a period. Availability is what's known and unavoidable within the current period: upcoming payments and money allocated to savings projects.
Credit spending and other debts acquired during the period are intentionally excluded, since they're paid in different ways and often extend into future periods.
The examples illustrate how availability, spending, and savings are calculated and updated throughout a period.
The system treats cash, credit, and savings as separate but connected states. This separation allows users to understand not only where their money is, but also what role it is playing.
- Cash represents money that can be allocated within the current period.
- Credit reflects spending that will impact future cash, not immediate availability.
- Savings projects reserve money with a specific purpose, removing it from what can be spent today.
Most financial tools emphasize past activity. MondayCall focuses on future decisions. By modeling periods, obligations, and savings upfront, the system helps users answer a simple but critical question at any moment:
How much can I spend without affecting what I need to pay or save next?
1 OF 4
One of the core decisions in MondayCall was to prioritize consistency across different user behaviors over absolute financial precision. Users manage credit and debt in very different ways. Some pay balances at the end of the period, others wait for the next income, and many pay over time.
Trying to model all of those behaviors inside a single availability number would introduce confusion and fragile logic. By limiting availability to what is known and unavoidable within the current period, the system remains predictable, understandable, and reliable for a wide range of financial habits.
2 OF 4
Saving is not treated as a single action, but as two distinct concepts: intent and execution.
Savings projects represent intent. They define why money is being saved and what it's reserved for. Savings methods represent execution. They define how money moves into those projects over time.
Even when both live in the same interface, separating these concepts allows users to set their direction once and let the system handle the mechanics consistently across periods.
3 OF 4
Not every decision needs to happen on the main screen. MondayCall distributes responsibility across focused surfaces, allowing users to act where context is strongest.
Cash decisions live in the period view, credit behavior is managed in dedicated credit surfaces, savings progress happens within projects, and the account view provides context and control.
This approach reduces cognitive load and prevents any single screen from becoming an overwhelming control center.
4 OF 4
Periods reset key values by design. Amounts such as spent, saved, and upcoming payments are recalculated at the start of each period.
This creates a clear mental boundary and prevents historical data from distorting present decisions. Instead of accumulating complexity over time, the system favors clarity at the beginning of every period.
Design decisions grounded in how money actually behaves.
Financial activity never stops, but systems that accumulate indefinitely become harder to understand and harder to use. MondayCall is built around income-based periods rather than calendar views. This allows users to reason about money within the same cycle in which it is earned, paid, and spent. By resetting key values at the start of each period, the system creates clear decision boundaries and prevents past activity from distorting future decisions.
There is no single correct way to manage money, especially when income cycles, credit card statements, and payment habits do not align. Instead of encoding assumptions about how users should behave, MondayCall prioritizes clear information over prescriptive tools. When a feature only works for a subset of users, it risks becoming confusing or misleading for the rest.
Savings rarely behave like money that is permanently gone. MondayCall treats savings as reserved intent during a period, while allowing flexibility outside the system. Saved amounts are moved at the end of each period to keep availability clear and prevent confusion in the next cycle, without attempting to control every external transaction.
MondayCall was designed as a system of rules, states, and reusable structures—not as a collection of isolated screens. The goal was to create a product that could scale in complexity without increasing cognitive load, allowing decisions, behaviors, and visual consistency to emerge from shared foundations rather than custom logic. This section focuses on how the system was structured and executed across design foundations, components, flows, and final screens.
A system built through libraries and templates, enabling consistency, speed, and scalable execution across platforms.
The color system was designed to communicate state, intent, and priority, rather than decoration. Colors reflect financial meaning (spend, recurring, saving), interaction states, and hierarchy, while supporting both light and dark modes from the same underlying structure.
A semantic color system designed to express financial states consistently across themes and surfaces.
Typography styles were defined to support clarity at different reading depths, from high-level summaries to detailed transaction views. Rather than relying on one-off text styles, the system establishes a small, intentional set of roles that scale across screens and flows.
Typography roles structured to support scanning, reading, and hierarchy across the product.
Icons were treated as part of the language of the system. A consistent icon set supports navigation, categorization, and action clarity, reducing the need for explanatory text while keeping visual noise low.
A unified icon system used across product actions, categories, and navigation.
Reusable components were created to standardize interaction patterns and accelerate iteration. These components act as building blocks, allowing screens to be composed quickly while maintaining consistency across states, platforms, and use cases. Rather than designing screens from scratch, most UI surfaces are assembled from shared components and screen patterns.
Reusable components and screen patterns designed to scale across multiple contexts.
The product is organized around a small set of core surfaces, each with a clear responsibility within the system. Flows connect these surfaces without duplicating logic, allowing users to enter the system from different points while preserving consistent behavior. This approach treats navigation and progression as part of the product architecture, not just UI wiring.
A high-level view of how core surfaces connect through shared system logic.
Specific flow cases were designed to validate how the system behaves across different entry points and scenarios. By reusing flow structures, the product supports variation without introducing fragmented logic or special cases. This ensures that complexity grows through composition, not exceptions.
Reusable flow structures applied across different user paths and entry points.
Final screen designs demonstrate how the system translates into real product surfaces across light mode, dark mode, and tablet layouts. Because screens are built from shared foundations and components, visual consistency is preserved while adapting to different devices and environments.
System-driven screens across light mode, dark mode, and larger form factors.
