Finance Archive — Case Study

01 / The context

The problem worth solving.

Most finance-learning resources separate explanations, formulas, practice questions, and practical applications into disconnected experiences. Learners can collect definitions without following a structured learning path, recognize concepts without testing their understanding, and understand formulas without applying them to decisions. The platform needed a consistent content model that could connect these activities while keeping financial calculations accurate and maintainable.

The product

Designed and developed a unified financial-learning platform around a typed Learn–Calculate–Apply content model. Each article combines structured explanations, a named calculator, a practical decision case, and self-check questions. A reusable finance engine owns financial calculations, while a centralized asynchronous read boundary serves typed seed records or MongoDB data without requiring changes to the UI.

02 / My contribution

Where I was involved.

Product design, content architecture, front-end development, and data-layer engineering. Designed the platform's content model and information architecture, implemented the reusable interface and finance-engine integration, developed the application read boundary and MongoDB repository, and established automated validation for financial calculations and core behavior.

03 / System approach

How the pieces fit.

The application follows a unidirectional dependency structure: UI → Feature → Application → Domain → Data. Next.js pages and components render content, feature modules manage workflows, and the application layer exposes shared asynchronous read functions. A React-free domain finance engine owns calculations, while typed seed records and the MongoDB repository provide data. The same read boundary supports seed-data fallback when a database is unavailable, while write operations explicitly require a database. AI-generated guidance is restricted to plain-language explanation; numerical results remain deterministic.

Next.js
TypeScript
MongoDB

04 / Engineering details

Inside the implementation.

01Enforcing a Consistent Learning Method

Requirement: Independent articles could otherwise develop inconsistent layouts, omit practical exercises, or duplicate financial formulas between explanations and interactive tools.
Implementation: Represented the Learn–Calculate–Apply methodology directly in the typed note record. Each article defines its sections, calculator kind, decision case, and self-check questions. The renderer uses that record to load the corresponding calculator without requiring a custom screen for every topic.
Result: Established a reusable content model in which the learning methodology is enforced by data rather than relying on individual page implementations.

02Keeping Financial Calculations Consistent

Requirement: Duplicating arithmetic across pages, charts, and interactive tools creates opportunities for inconsistent results and makes financial logic harder to test independently.
Implementation: Created a React-free finance engine responsible for financial calculations, including statements, valuation, risk, and formula experiments. Interface components consume its outputs instead of implementing their own calculations.
Result: Centralized calculation logic and validated financial outputs through automated tests. The documented benchmark cases include bond pricing, Gordon growth valuation, CAPM, WACC, and project IRR.

03Separating Data Access from the Interface

Requirement: Pages coupled directly to database access would become harder to maintain and would behave differently when the database was unavailable during development or deployment.
Implementation: Introduced a shared asynchronous application read boundary for notes, formulas, and practice items. The underlying repository reads from MongoDB when available and falls back to typed seed records when appropriate.
Result: Kept the component tree independent of the underlying read source and enabled the demo and test suite to exercise the same application interfaces.

04Diagnosing a Misleading Database Failure

Requirement: The application reported that the database was configured and continued serving seed data, yet write operations returned HTTP 503. A dynamically assembled MongoDB driver import was not analyzable by Turbopack and was replaced with a stub that failed at runtime.
Implementation: Replaced the dynamic import with a literal mongodb import and declared the driver as a server external package. Separated driver installation status from database connectivity, improved seed-route diagnostics, and stopped caching driver failures.
Result: Made driver installation and connection state distinguishable, exposed the underlying failure instead of masking it behind a generic response, and allowed driver failures to recover without requiring a process restart.

05Maintaining Consistency Across Content Sources

Requirement: Authoring content in the browser and maintaining typed seed files could create two competing representations of the same document, complicating validation and database seeding.
Implementation: Used a shared validated document model for browser-based authoring and typed seed records, supported by a seed plan that keeps the seed data and MongoDB representation aligned.
Result: Established a single content model across authoring and seeding, with 303 seed documents distributed across 13 collections.

Product capabilities