I build Flutter apps that hold up outside the demo — offline, on a bad network, on a mid-range Android phone.
Start from the user's problem, not the widget tree.
Keep Flutter out of the domain layer, so the interesting parts stay testable without a device.
Design for no signal, low memory, interrupted taps — real conditions, not the happy path.
Maintainable over clever. I'll be the one reading it in six months.
Mobile
Backend & Data
Tooling
📚 Zeolite — Know exactly how many classes you can afford to miss
An offline-first attendance tracker that answers one question before you skip a lecture.
| Rules, not rows | A weekly class is stored as a rule and expanded into occurrences on demand. Editing a rule reshapes every future week instantly, and the database stays tiny. |
| Time that doesn't drift | Dates as yyyymmdd integers, times as minutes since midnight — immune to timezones and DST. |
| Marks that survive edits | Attendance is keyed by (subject, date, start time), not slot id, so a mark outlives the rule that produced it. |
| Testable by design | The domain layer never imports Flutter. 80 tests cover the schedule engine, stats formulas, notification gating, and palette contrast ratios — no device needed. |
Can skip ⌊p / t⌋ − h
Must attend ⌈(t·h − p) / (1 − t)⌉
No accounts. No server. No network calls. Works on a train with no signal.
🛒 KursKart — Multi-store e-commerce, full stack
A Flutter client and a Node/Express/MongoDB API in one monorepo.
| Can't oversell | Checkout reserves stock with a conditional update per product. If any line fails, reserved stock is released and the cart is left untouched. |
| Immutable orders | Order lines copy name, price and image at purchase time, so editing a product later never rewrites history. |
| Runs two ways | The same Express app runs as a normal server and as a serverless function, with a cached Mongo connection shared across warm invocations. |
| Security defaults | bcrypt hashing, JWT in flutter_secure_storage, API URL as a --dart-define, cleartext HTTP in debug builds only. |
| Building | Polished Flutter products that survive real device constraints |
| Learning | Architecture patterns for apps that keep growing |
| Improving | Repositories documented well enough to read as case studies |
| Open to | Flutter roles, collaborations, and interesting mobile problems |
