Interesty

Interesty is an internal financial operations system I built for a local Taiwanese team. I turned an investment-contract workflow that had been held together by paper records, human memory, and manual cross-checking into a contract-centered system that can take over day-to-day work. The project was not limited to contract entry. It brought payouts, renewals, monthly reporting, external imports, and review into one working structure, so a fragmented and delay-prone process became easier to query, trace, and maintain.

The team originally worked from paper and only entered data into Excel about every six months. Those files were delayed summaries rather than reliable operational records. Their formats were inconsistent, their precision was unstable, and many of the fields the system actually needed were missing. Each month, users had to compare payouts across periods, then trace contracts one by one to check maturity, renewal, principal repayment, and participant changes. As volume grew, the workflow became heavily dependent on experienced operators and manual judgment, which made it hard to hand over and hard to sustain.

This was a solo project that I pushed from start to finish. The scope covered historical data cleanup and migration, core data model and rule design, full-stack system delivery, mobile and desktop access, and operational capabilities such as backup, restore, and auditability. The work was not just about building features. It was about turning a person-dependent workflow into a formal process the system could actually carry.

This project did not begin from a clean requirement. It began from a workflow that was already running, but with missing data, inconsistent structure, and heavy dependence on manual judgment. I first cleaned and reconstructed historical paper and Excel data so it could enter the system with the required fields, relationships, and constraints in place. I then brought contracts, payouts, renewals, imports, review, and monthly reporting into one shared model and workflow. I also shaped the system around a contract-centered structure: payouts are generated from contracts, renewals are formal relationships, and reports, variance analysis, and external imports all rely on the same state and relationship model.

The frontend uses React/Vite, and the backend uses FastAPI with PostgreSQL as the system of record. Frontend delivery and formal data processing are deployed separately: the frontend runs on Cloudflare Pages, while the backend and PostgreSQL run on a self-controlled machine. The database is only reachable locally through the backend, so formal data is not exposed directly to the public network. This split keeps day-to-day access lightweight while leaving formal data, backup, and recovery inside a more controllable boundary.