Moniager

Product concept

Many finance applications model transactions as private ledger entries. Moniager adds a social accountability layer: a user can associate an event with a counterparty, share a review request, and preserve a mutually visible status. The purpose is clarity and relationship trust, not replacing formal accounting or banking systems.

The public product describes personal accounts, banks/cards, income and expense categories, counterparties, debts/receivables, shared expenses, notifications, reminders, and a mobile-accessible web application. Those descriptions indicate product scope, not independent proof that every state or permission path is complete.

Privacy-safe transaction workflow

The important domain boundary is between a user's private financial record and a shared transaction state. Invitation, review, confirmation, rejection, and later edits need explicit state transitions, idempotent notification behavior, and authorization rules that remain safe when one participant is removed or loses access.

Technical architecture

The local product repository contains a Django/DRF backend and a React frontend. The product direction includes accounts and transactions, contacts/counterparties, shared transaction confirmation, debt/credit workflows, shared expenses, invitations, notifications, attachments, and localization. The public product site demonstrates real interface screenshots and links to the application; this case study uses a public marketing-page dashboard image rather than authenticated customer data.

Financial values require exact decimal handling and explicit currency semantics. Cross-user interactions require object-level authorization and careful control over what is disclosed in a notification, share link, or public route. Notification delivery should be treated as retryable and observable rather than the source of truth for transaction state.

Privacy and security

Financial privacy changes the default design: transaction descriptions, counterparties, amounts, attachments, and reminder text are sensitive. Authorization must be checked at every API boundary; unguessable identifiers are not sufficient access control. Shared access should be scoped to the specific intended record, revocable where appropriate, and auditable.

Earlier repository work includes security defect reports, including a transaction-title HTML injection finding marked fixed in that report. A report’s fix status does not establish the current branch’s full security posture. The current snapshot has uncommitted auth/frontend changes, so this portfolio makes no claim of completed penetration testing, production security approval, or comprehensive privacy compliance.

Product interface

Current limitations and lessons

• Current security and privacy posture has not been independently reassessed across the whole application.
• Notification delivery reliability and complete state-transition behavior require dedicated end-to-end evidence.
• Data access across shared accounts and multiple participants needs object-level authorization tests, not just UI hiding.
• Currency conversion, financial rounding, and historical-value rules should be explicit and tested.
• PWA/SPA presence does not prove offline consistency, store distribution, or full mobile acceptance.

Role and contribution

I shaped the product’s shared-accountability concept and translated a familiar social problem into a set of explicit financial and interpersonal workflows. The key design challenge is preserving user control while making a shared event understandable to both parties.