What Inspired SEEn

I have been wearing glasses since the 3rd grade. They are part of me now — so much a part of me that on the days I forget to put them on or leave my contacts out, I feel it immediately. I can't see. I can't focus. I can't show up the way I want to. And I am one of the lucky ones.

What about the girl who feels that every single day — not because she forgot her glasses, but because she never had access to eye care at all? What about the girl who is already fighting just to be in a classroom, and then cannot even see what is on the board?

I went looking for tools that could help. Nothing was free. Nothing was browser-based. Nothing was built for her.

So I built it.

SEEn is not a replacement for eye care. It is what exists when eye care does not — a free, browser-based tool that lets a girl point her phone at the blackboard and actually see what's being taught, because every young girl deserves to be seen.


How I Built It

SEEn is built using Lovable as my AI-assisted development platform. As a builder with a low coding background, I chose to use the tools available to me and focus my energy on product decisions.

The core stack:

  • React 18.3.1 + Tailwind CSS — single-page mobile web UI
  • Vite + TypeScript — fast build tool and type-safe codebase
  • HTML5 getUserMedia API — live camera feed, fully on-device
  • CSS filter (contrast/brightness) + transform: scale() — real-time clarity adjustments, no server processing
  • @react-three/xr + Three.js v0.150.0 — WebXR layer with silent fallback for unsupported devices
  • shadcn-ui — accessible pre-built UI components

Every product decision was intentional:

  • Chose the Snellen letter chart — the traditional, universally recognized eye exam format
  • Chose tap responses over reading letters aloud — letters are pronounced differently in every language
  • No backend, no login, no stored data — what she sees stays on her phone, always, protecting her privacy

What I Learned

  1. Strong planning makes building faster and more efficient. Taking time to map out each feature before writing a single prompt leads to better outcomes — less back and forth, fewer rebuild cycles, cleaner code.

  2. AI tools are tools — not decision-makers. I can push back, override, and direct them toward the outcome I want. The clearest example: The first disclaimer generated stated that users should see an eye care professional. I removed it. The people SEEn is built for cannot afford an eye doctor.

  3. AR/XR/VR behaves differently across devices and browsers. The immersive-AR experience on Chrome for Android is not the same as what a user gets on Safari.

  4. The browser camera is not plug-and-play. One line of code gets you a camera feed. Getting it to actually work — right resolution, right camera, right defaults, right reset — is an ongoing learning process. The camera is not as sharp as I would like it to be. That's my v2.

  5. Always test as your end user, not as the builder. I discovered that performing a self-guided eye exam is harder than it sounds — if your vision is already blurry, you cannot read the buttons you need to press to take the test. My workaround was to read the buttons first, then begin the test. That insight is now on my v2 roadmap: a brief guided setup screen before the exam starts, so the user is oriented before her vision is being tested.


Challenges I Faced

WebXR compatibilityimmersive-AR is not supported on iOS Safari. Solved with a silent fallback via @react-three/xr so unsupported devices load a standard camera overlay with no crash and no error shown to the user.

Build error — A Three.js SRGBColorSpace import was breaking the entire build. Upgrading to v0.150.0 fixed it.

Medical device risk — A vision app can easily be perceived as a medical device. Kept all language to "assistive clarity tool only" with one honest disclaimer: This near vision screening is not a replacement for a full eye exam. No diagnosis. No prescription. No overclaiming.

Design consistency — Lovable's default design did not match my vision for SEEn. I designed the full UI in Canva first, then rebuilt the design system mid-build — cream/coral palette, Poppins typography, WCAG AA 4.5:1 contrast — to match the brand and meet accessibility standards at the same time.

Getting the camera to behave — The browser defaulted to 640×480, stretched to fill the screen. Default sliders were set to 150% contrast and 1.5× zoom — not neutral, not useful. The Reset button was pulling a cached preset instead of resetting to zero. The camera is still not as sharp as I would like it to be. Plan to fix in v2.

Built With

  • canva
  • css-filter-(contrast/brightness)
  • github
  • html5-getusermedia-api
  • lovable
  • react-18.3.1
  • shadcn-ui
  • tailwind-css
  • three.js
  • typescript
  • vite
  • webxr
Share this project:

Updates