← All work 03 · Mobile product · Machine learning

SmartReceipt

Receipt logging with on-device OCR, offline and automatic.

100% offline · automatic classification

Role Project Manager · ML developer Team 4 people Period October 2026
Repository ↗
Flutter ML Kit TF-IDF + NB SQLite
SmartReceipt — Mobile product · Machine learning
Light-mode home — this month’s spending summary
Light-mode home — this month’s spending summary
Dark-mode home with per-category breakdown
Dark-mode home with per-category breakdown
Light-mode splash screen
Light-mode splash screen
Dark-mode splash screen
Dark-mode splash screen
Receipt scan result and automatic classification
Receipt scan result and automatic classification
Receipt history stored on-device
Receipt history stored on-device
6.026 Training samples
1.419 Unique products
15 Categories
0 Server dependency
Role
Project Manager
Team
4 people
Duration
1 month
Type
Project-based learning

Context & problem

Manual expense tracking gets abandoned quickly because it is tedious. Receipts already hold the data, but as noisy thermal text: abbreviations, typos, and store-specific formats. The data also must not leave the device.

Role & responsibilities

I owned project planning and the machine-learning model. Two members built the app and interface, one handled data and evaluation; I also kept model decisions aligned with product decisions.

Planning

I reversed the usual order: model and data first, interface second, because model quality decides how much manual correction users face. One rule was non-negotiable: the model runs entirely on-device.

Coordination

A small team with a one-month deadline meant brief daily coordination. What I protected was the data contract — category names, codes, and result structure — so both sides could integrate without surprises.

Progress monitoring

The model was measured with a confusion matrix and per-category accuracy, not a feeling that it "looked good". The test set was split by unique product so nothing leaked into training. The app was measured by one receipt going from photo to stored record.

Risks & responses

Risk Model accuracy looking high because of leakage between train and test.
Response Dataset split by unique product, not random rows.
Risk OCR text too noisy to classify reliably.
Response Text normalisation and abbreviation expansion before classification, plus a “needs review” path when the model is unsure.
Risk A server-dependent model breaking the privacy constraint.
Response Model trained offline then executed on-device with weights bundled in the app.

Outcomes

  • The app can photograph a receipt, recognise text, and group items into categories automatically.
  • Spending analytics and receipt history available without an internet connection.
  • User corrections are stored as additional training data to improve the model.
  • Met the project-based learning target as expected by the course.

What I would do differently

I learned that measuring a model is not a one-off task. The first version looked accurate, but once tested on products it had never seen, errors concentrated in similar categories — food and beverages, for instance. Going forward I will prepare a test set from a different source from the start, not just split the same data.

Artifacts

Documentation reconstructed from project archives for portfolio purposes.