I build to learn.
I learn to build better.

The problem

People end up with hundreds of screenshots and no way to find the one they need — a receipt, a website link, a travel booking — without scrolling through everything.

My role

Built the on-device intelligence layer and the sync layer: tagging, categorization, and getting that data reliably on and off the device.

The interesting part

Combining Core ML and Vision to read content out of an image — not just store it — so the app can generate tags like "work," "travel," or "documents" automatically.

Engineering / under the hood

Core ML pre-trained models and custom classifiers detect objects, scenes, and patterns in each screenshot; Vision processes the image data. Photos sync to a private CloudKit container, with a separate CloudKit-backed library isolating sensitive configuration from the main app. Core Data entities are transformed to and from JSON to keep local storage and the server in sync, including nested relationships.

Challenges

Mapping complex, nested Core Data relationships onto JSON without losing data integrity, and keeping sync fast enough that it never feels like it's blocking the UI. Scaling CloudKit usage and holding to its encryption and security requirements as the user base grew.

What I learned

Smart tagging is only as good as the sync underneath it — the ML model can be perfect and the app will still feel broken if data doesn't move reliably between device and cloud.

The problem

Most IoT devices lean on Wi-Fi for everything, but local, low-latency communication with nearby sensors needed a lighter-weight protocol.

My role

Built the device pairing flow and the Bluetooth communication layer between the app and RITA's hardware sensors.

The interesting part

Onboarding a physical device entirely inside a mobile app — start the device, connect to Wi-Fi, then discover and pair individual sensors (droplet valves, soil moisture, light and rain detection) one by one.

Engineering / under the hood

CoreBluetooth handles transmitting and receiving signals over Bluetooth 5.0 Low Energy between the app and each connected sensor, favored over Wi-Fi for local, low-power communication with the hardware.

Challenges

Keeping the pairing experience simple when the underlying process — discovering peripherals, negotiating connections, handling sensors that fail to connect — is inherently unpredictable.

What I learned

Designing for hardware means designing for failure states first: a sensor that says "Not Connected" needs to feel like a normal part of the flow, not an error screen.

Some detail below is inferred from screenshots only — marked placeholders are ready for Udani to fill in.

The problem

Riders need a safe way home when they can't drive themselves, and drivers need a clear, trustworthy way to see trips, earnings, and their route in one place.

My role

Worked across both apps in the pair — the rider-facing booking and safety experience, and the driver-facing trip and earnings dashboard.

The interesting part

Designing two apps that share a domain model but serve opposite jobs: one is about confidence and safety in a vulnerable moment, the other is about clarity and trust in day-to-day earnings.

Engineering / under the hood

Live trip state (matching, driver en route, in progress, completed) drives the UI on both sides, with map-based tracking, a package of in-trip safety tools (SOS, live trip sharing, masked calling) on the rider app, and a weekly earnings breakdown with trip-level detail on the driver app.

Challenges

Placeholder — exact technical decisions behind the real-time matching and trip-tracking layer weren't part of the material reviewed for this site. Udani: happy to fill this in with the real architecture.

What I learned

Placeholder — add the key engineering takeaway from this project.

Some detail below is inferred from screenshots only — marked placeholders are ready for Udani to fill in.

The problem

Financing a phone purchase means the lender needs real collateral protection without the borrower losing full use of the device once it's paid off.

My role

Placeholder — Udani to confirm exact scope of work on VOLA for this write-up.

The interesting part

The device itself is the collateral: MDM keeps the phone secured and auto-locks it if a payment is missed, then releases automatically once the loan is repaid.

Engineering / under the hood

The flow runs from device selection and provisional valuation, through NIC photo and video KYC verification, to a repayment schedule with per-installment status and an MDM-backed device security screen.

Challenges

Placeholder — exact technical decisions weren't part of the material reviewed for this site.

What I learned

Placeholder — add the key engineering takeaway from this project.

Some detail below is inferred from screenshots only — marked placeholders are ready for Udani to fill in.

The problem

Ordering a gas cylinder for home delivery needed to be as simple as reordering something you buy every month — pick a product, confirm an address, pay, done.

My role

Placeholder — Udani to confirm exact scope of work on this app for this write-up.

The interesting part

A consumer commerce flow layered on top of a real-world dealer and delivery network, including repeat ordering from past dealers.

Engineering / under the hood

Product selection, cart and delivery-charge calculation, cash or card-on-delivery payment, and order history with one-tap reordering, all backed by REST APIs.

Challenges

Placeholder — exact technical decisions weren't part of the material reviewed for this site.

What I learned

Placeholder — add the key engineering takeaway from this project.

The problem

The app rewards users with credits for watching video ads, which only works if the app can be sure the ad was actually watched, not skipped.

My role

Built the custom video player that the entire reward mechanic depends on.

The interesting part

A standard AVKit player lets people skip or scrub past the content — so watching properly had to be enforced at the player level, not just trusted.

Engineering / under the hood

AVFoundation and AVKit were integrated to play the ads, with a bespoke player layered on top that captures current playtime and disables tap-to-pause for the duration of the ad.

Challenges

Getting AVFoundation and AVKit to work together cleanly while adding non-standard playback restrictions that fight the frameworks' default behavior.

What I learned

Sometimes the interesting engineering problem isn't the feature itself, it's taking away the interactions a framework gives you for free.