Independent project · September 2021 – Ongoing
An evolving iOS finance tracker shaped around fast income and expense logging, flexible categories, and a codebase that can grow with the product.
FinTrack began as a practical exploration of how everyday money tracking could feel immediate without making the underlying code difficult to extend.
Personal-finance tools can make a small task feel heavy. The core challenge was to keep transaction entry, categories, history, and settings understandable while leaving room for budgeting and financial-goal features as the product evolves.
As the independent developer, I own the product direction, interaction choices, UIKit implementation, data structures, and the work of turning each iteration into a more maintainable foundation.
These simulator captures come from the public FinTrack repository and show the project’s early transaction-entry and history flows.
The screenshots document an early build and are intentionally labeled as such. The project is ongoing; this project does not claim adoption, revenue, or performance results that have not been measured.
The architecture direction gives UIKit screens clear responsibilities while keeping transaction and user data away from presentation details.
The current direction is less about adding surface area quickly and more about making future product work safer to change.
UIKit provides explicit control over navigation, reusable controls, and interaction behavior while strengthening practical iOS engineering depth.
Separating presentation state from view controllers reduces the pressure to place product logic directly inside screens as the feature set grows.
Early simulator screens remain useful proof of a working product, but they are presented as an iteration — not disguised as the current finished interface.
The result is a real, evolving product foundation — not a polished claim without code behind it.
The public repository demonstrates the path from an idea to a running iOS application and provides a transparent baseline for continued work.
The main lesson is that product clarity and architecture should evolve together: each interface improvement is easier to sustain when responsibilities are explicit.
