In-house Projects

Task Manager & Test Runner

Both Task Manager and Test Runner expose a REST API that serves two entirely different clients from the same codebase: a server-rendered web interface using session cookie authentication, and a native Flutter mobile app using API key headers. This is a deliberate architectural choice that avoids the typical outcome of divergent backends — where the mobile API drifts from the web backend over time and eventually becomes a maintenance burden.

The shared backend pattern requires discipline in the API contract: routes must return clean JSON without assuming a browser on the other end, authentication middleware must handle both schemes without coupling them, and error responses must be meaningful to both a rendered error page and a Flutter error handler. Getting this right from the start means new features added to the backend are immediately available to both clients without duplication.

List Manager & My Steps

Both List Manager and My Steps are built around a local-first data model: SQLite is the source of truth on the device, and the app works fully without network connectivity. This is the right design for personal productivity and health tracking tools, where the absence of connectivity should never block the user from doing the task the app exists to support.

The tradeoff is sync complexity. My Steps addresses this with incremental sync: on launch the app queries Health Connect for the last sync timestamp and fetches only the delta, with a full historical backfill on first run. List Manager takes a simpler approach — single-device, no sync — which is the right call for a personal list tool with no multi-device requirement. Knowing when not to build a feature is part of the design.

Let's Split It

The naive approach to group expense settlement — asking everyone to pay everyone they owe directly — scales badly. For a group of n people this produces up to n×(n−1)/2 separate transactions: fifteen payments in a group of six. Let's Split It uses a greedy algorithm instead: compute each person's net balance, then repeatedly pair the largest creditor with the largest debtor, settling as much as possible per transaction until all balances reach zero. This always produces the minimum number of transactions needed, in O(n log n) time.

The algorithm was designed before a line of code was written — identified in the scoping conversation as a core requirement, not an optimisation to add later. Retrofitting a settlement algorithm into a data model designed around direct payments would have required a schema change and a rewrite of the results view.

My Steps

Samsung Health stores step count data on-device but provides no native export mechanism for external systems. My Steps solves this through Google's Health Connect SDK, which acts as a structured data bridge: the app requests permission to read step data from Health Connect (which Samsung Health writes to), retrieves it at the required granularity, and POSTs it as JSON to any HTTP endpoint the user configures — Home Assistant automations, InfluxDB instances, personal dashboards, or custom backends.

The non-trivial part was not the HTTP export but the historical backfill on first install. Health Connect can hold months or years of data. Fetching it in a single request risks out-of-memory errors on lower-end devices. My Steps pages through history in weekly chunks, writing each batch to local SQLite before moving on, and resumes from the last synced date on subsequent launches — making the initial sync restartable and the ongoing sync lightweight.