Naman

Problem

The original web version of Panda Letter worked for exactly one relationship, with no accounts and no audience — the entire trust model was 'nobody else has the link.' Rebuilding it as a public Android app meant scaling that intimacy to many users without turning it into a social feed, a dating app, or a scrapbook with ads.

Approach

• →Designed a Clean Architecture split into :core:* and :feature:* Gradle modules (auth, letters, memories, timeline, search, sharing, settings, growingtogether) so feature modules never depend on each other — a solo maintainer can touch one feature eighteen months from now without re-reading the whole codebase.
• →Room (encrypted with SQLCipher) is the single source of truth for every screen; Firestore sync runs entirely through WorkManager so uploads survive process death and never block the UI.
• →Wrote a full Software Design Document before writing code — architecture rationale, data model, security model, and a 16-section spec covering everything from Firestore rules testing to phased delivery — treating a personal project with the same rigor as production software.
• →Designed 'Growing Together', a shared-commitments feature, around an explicit anti-pattern list: no streaks as the primary metric, no plain done/not-done checkbox, no public activity feed — a missed day is recorded as one of four states (Completed/Skipped/Couldn't today/Pending) so it's never presented as failure.
• →Enforced authorization with Firestore and Storage Security Rules rather than client-side checks alone, with a passing and a failing test required for every new rule.

Outcome

A modular, offline-first Android app with a design system carried over deliberately from the original web app (soft palette, serif display type for titles, gentle motion) rather than a generic Material reskin — currently in active development, phased deliberately so the MVP stays dogfoodable before any feature beyond it ships.

Problem

High-quality image upscaling is either a technical desktop tool (Photoshop-grade, but requires expertise and horsepower) or a simplified mobile app with limited enhancement capability. Scanify's brief was to put state-of-the-art GAN-based super-resolution — normally a heavy neural network — inside a phone-friendly app without pretending the phone itself does the inference.

Approach

• →Built a three-tier system: a native Kotlin/CameraX Android client, a Flask API server handling auth and request orchestration, and a Real-ESRGAN model served from a cloud GPU environment — decoupling UI, application logic, and neural processing into independently replaceable layers.
• →Investigated and benchmarked traditional interpolation (bicubic, Lanczos3), classic CNN super-resolution, and GAN-based approaches before selecting Real-ESRGAN for its degradation modeling (handles blur, noise, and compression artifacts simultaneously, not just upscaling).
• →Profiled the pipeline across hardware configurations (including batched runs on Tesla T4 GPUs) and tuned tiling to keep memory use bounded on high-resolution inputs.
• →Ran a formal usability study — System Usability Scale questionnaire, task-completion analysis, and think-aloud protocol across 20 participants — rather than shipping on intuition.
• →Benchmarked the finished system head-to-head against Adobe Photoshop's Super Resolution, Remini, Let's Enhance, and Lanczos3 interpolation on quality, speed, and cost.

Outcome

A working mobile-cloud image enhancement system with quality competitive with commercial desktop software and measured usability in the top decile of mobile apps — documented end-to-end in a 99-page technical report covering requirements, architecture, algorithm selection, implementation, and formal evaluation.