The virtual try-on (VTO) market is projected to hit $15.29 billion in 2026. Yet, despite this explosive growth, only 1.4% of shoppers use it regula...
For further actions, you may consider blocking this person and/or reporting abuse
Yes please don't forget to share the technical journey. But how are you going to make it accurate enough? Also we can't run big models on a $150 phone right?
effessdev, that is the exact right question to ask! You hit the nail on the head: running a massive diffusion model locally on a budget device is a massive engineering challenge.
That’s exactly why ACA is being built in two distinct phases to be realistic about hardware limits:
Phase 1 (The MVP): We are validating the workflow and user experience using a lightweight, cost-effective API. This proves people actually want the privacy-first workflow without us burning battery or compute locally just yet.
Phase 2 (The Moat): This is where the real engineering happens. We aren't trying to run a 1.5B parameter model on day one. The goal is to leverage highly distilled, mobile-optimized architectures (like the 415M parameter Mobile-VTON) combined with aggressive quantization (4-bit/8-bit) and WebGPU/WASM optimizations.
Will the initial local version be as fast or high-res as a cloud server? No. But the trade-off is absolute privacy. Even if the local version is slower or initially limited to specific garment types (like basic t-shirts), it proves the core concept: zero data leaves the device.
I’ll be documenting every single bottleneck, benchmark, and failure along the way. The $150 phone constraint isn't a bug; it’s the ultimate stress test for efficient, accessible AI. 🐯📱
Why do your replies look sooo AI-generated? 😭
Haha, you caught me! 😂 I’ll be 100% honest with you: I do use AI to help me polish my replies.
Typing out long, technical explanations on a $150 phone is really slow, and I want to make sure I’m communicating my ideas clearly. I basically use AI as a super-powered spellchecker and editor to structure my thoughts.
But I promise you, the code, the architecture, the bugs, and the 3 AM frustrations of trying to get these models to run on a budget device are 100% human. The AI doesn't know how to fix a Supabase RLS error or figure out why a quantized model is crashing my phone. That’s all me. 😅
You’re totally right though, I should probably dial back the "corporate dev speak" and just talk like a normal builder. Thanks for keeping me honest!
But seriously, I’d love to know your actual thoughts on the technical approach. If you were trying to run this on a low-end device, how would you tackle it?
I'd prefer unpolished replies, honestly 😅
Haha, fair enough! 😅 I'll drop the fancy formatting then.
Honestly, it's just me typing this out on my phone right now, trying to figure out how to get these models to run without melting my battery. The documentation for mobile VTON is pretty messy, and I'm mostly just trial-and-erroring it in Termux at this point.
If you have any actual tips on running lightweight models on low-end hardware, I'm all ears.
Thanks for keeping it real with me though, I genuinely appreciate it! 🐯
Nice!! i have a few questions tho:
Even with 4-bit quantization, running a 415M parameter model alongside the app runtime, browser DOM, and memory overhead eats up hundreds of megabytes. How are you handling OOM (Out of Memory) crashes when the browser garbage collector kicks in on a low-end device?
You mentioned relying on WebGPU/WASM for local inference. Have you actually checked what percentage of sub-$150 Android devices in markets like India even have reliable, non-crashing WebGPU drivers out-of-the-box in mobile Chrome? Most budget chipsets lag way behind on Vulkan/WebGPU support.
If a user tries to run a local VTO pass on a budget phone, the thermal throttling will spike instantly. Have you benchmarked how many seconds it takes for a $150 processor to thermally throttle, and what kind of battery drop a single inference causes?
adam, these are brutally accurate questions. You just named the exact three problems I’m losing sleep over.
OOM Crashes: You're completely right. Running a 415M model alongside the browser DOM on a low-end device is a recipe for the garbage collector to panic. That’s why the pure browser-based WASM route is likely a dead end for Phase 2. The realistic pivot is a lightweight native wrapper (like React Native with ONNX Runtime or MediaPipe) that can tap directly into the device's NPU, bypassing the browser's memory overhead entirely.
WebGPU Fragmentation: Spot on. Budget chipsets (especially older MediaTek or Unisoc boards common in India) have notoriously spotty Vulkan/WebGPU support in mobile Chrome. Relying on the browser for heavy compute is a gamble. This is another reason why native API access (NNAPI) is the only viable long-term path for true on-device inference on these phones.
Thermal Throttling: I haven't run formal benchmarks yet, but anecdotally, my $150 phone gets warm just running Termux compilations. A heavy local inference pass will throttle and drain the battery. The UX solution here isn't to hide it, but to be transparent: give the user a clear choice. "Local processing is 100% private but will take ~60 seconds and use more battery. Tap here for instant (but server-processed) API mode."
I don't have all the answers figured out yet, but you just validated exactly where the real engineering bottlenecks are. If you have any specific libraries or native mobile ML frameworks you've had success with on budget Android devices, I am all ears.
Thanks for the incredibly sharp reality check. 🐯📱