Cognitive Finance MVP: From Prototype to Production-Ready Architecture

The Win

Engineered a robust financial MVP that moved from a fragile prototype to a production-ready system. By implementing a cognitive classification layer and a domain-driven architecture, I achieved 100% test coverage for core financial logic.

• 400+ automated tests protecting the financial domain.
• AI-powered classification with local rules fallback for cost optimization.
• Multi-workspace isolation ensuring 100% data privacy for mentorship students.

Situation

Financas Inovai Labs was born from a real pain point: managing personal finances without relying on manual spreadsheets, scattered messages, or bank statement screenshots. The problem was even more pronounced in the context of financial mentorship. The mentor needed to track progress, spending patterns, and evolution without invading privacy, without receiving unstructured data via WhatsApp, and without building an operation that was impossible to scale.

The product had gone through previous iterations, but the domain foundation didn't yet support what really mattered: reliable cash flow. Single, installment, and recurring transactions, along with transfers, needed to be represented explicitly so that dashboards, goals, intelligent imports, and mentorship monitoring were trustworthy.

The decision was to restart the v3 version without discarding what already worked. Backend, authentication, parsers, deployment, and part of the infrastructure were preserved. The build order changed: first correct the financial domain, then visualization, import, AI, mentorship, and goals.

Task

I acted as founder, full-stack architect, and tech lead for the v3 restart. My responsibility was to transform an idea validated in personal use and mentorship into a responsive web product with a modular backend, consistent financial model, bank statement import, automatic AI classification, and an experience suitable for real use by both mentor and student.

The expected success wasn't just "having screens." The goal was to reach a production-ready MVP with data isolation per workspace, automated tests, quality reviews, and a foundation ready for a pilot with real users. I also coordinated the process via AIOX: PRD, architecture, design system, stories, implementation, QA gates, and deployment.

Action

Architecture

The architecture maintained a monorepo with backend and frontend. In the backend, I used modular NestJS with Prisma and Supabase PostgreSQL, separating responsibilities by domain: authentication, workspaces, accounts, transactions, categories, dashboard, import, AI, classification rules, mentorship, budgets, goals, and notifications.

In the frontend, I used React 19, Vite, TailwindCSS, Shadcn/ui, React Query, and Recharts to build a mobile-first interface with a personal dashboard, cash flow tracking, categories, bank statement import, post-import review, classification rules, student onboarding, and mentorship screens.

flowchart LR
  User["Student / Mentor"] --> Web["React 19 + Vite"]
  Web --> API["NestJS API"]
  API --> Auth["Supabase Auth"]
  API --> DB["Supabase PostgreSQL via Prisma"]
  API --> Import["OFX / CSV / PDF import pipeline"]
  API --> Rules["User classification rules"]
  Rules --> AI["OpenRouter fallback"]
  API --> Redis["Redis async support"]
  Deploy["GitHub Actions"] --> Runtime["Docker Compose production runtime"]
  Runtime --> API

Technical decisions

The first decision was to preserve existing infrastructure and rebuild the product's priorities instead of rewriting everything. This reduced risk and kept deployment, auth, parsers, and CRUDs as a reusable foundation. The trade-off was carrying some old decisions longer, but the alternative would have delayed the financial domain validation.

The second decision was to fix the financial domain before building the screens. Entities like TransactionNature, TransactionType, InstallmentGroup, RecurrenceRule, and TransferLink were treated as the MVP's foundation. Installments need to appear in future cash flow and be reconcilable with statements; indefinite recurrences shouldn't pollute the database with years of rows.

type TransactionType = 'single' | 'installment' | 'recurring' | 'transfer'
 
interface PlannedTransaction {
  workspaceId: string
  accountId: string
  type: TransactionType
  amountCents: number
  dueDate: string
  installmentGroupId?: string
  recurrenceRuleId?: string
  transferLinkId?: string
}

The third decision was to use manual user rules before AI. AI via OpenRouter comes in as a fallback or suggestion, avoiding unnecessary cost and latency when a local rule resolves the classification. This also improves system explainability: when the user corrects a category, the correction becomes reusable behavior.

The fourth decision was to maintain isolation per workspaceId in the NestJS backend, with guards and filtered queries. Since Prisma uses service role credentials in various flows, I didn't want to rely exclusively on RLS in Supabase. Domain-level control in the API made privacy rules more auditable for mentorship, especially since the mentor accesses aggregated data, not individual transaction details.

Trade-offs

The MVP prioritized manual OFX/CSV/PDF import over Open Finance. This simplified compliance, reduced initial cost, and allowed validating the product flow before integrating external providers.

Some business metrics still depend on the real pilot with students. Therefore, the metrics publishable in this version focus on delivery, quality, and technical readiness. The Telegram bot and receipt OCR were also left for post-MVP; the modular base exists, but the case focuses on the web application and core financial flow.

Result

Metrics

The main result was transforming a financial app that still relied on an incomplete foundation into a product with a consistent financial domain. Starting with v3, cash flow, import, and mentorship began relying on explicit models for installments, recurrences, transfers, classification rules, and privacy.

The AIOX process created strong traceability: every relevant change went through PRD, architecture, story, implementation, checklist, and QA gate. This makes the case relevant for a portfolio because it shows not just the final interface, but also the ability to lead product, architecture, engineering, and quality in a real system.

Learning

The most important decision was not to accelerate UI and automation while the core domain was still wrong. The v3 restart prioritized correct modeling of transactions, installments, recurrences, transfers, and privacy before expanding the visual experience. For interviews, the best angle is to present the project as the transformation of a functional prototype into an operable MVP.