The Build-vs-Buy Decision That Shaped EyeBrowse

Every technical decision is a business decision. The question is whether anyone recognizes it at the time.

EyeBrowse — a virtual try-on platform for independent eyewear retailers — faced its first major architecture call on the AR pipeline. Customers need to see glasses on their face in real-time. That is the entire product. Get it wrong, and nothing else matters.

There were two paths: license a commercial virtual try-on (VTO) vendor like FittingBox, Ditto, or Perfect Corp, or build a custom pipeline on top of Google's open-source MediaPipe. The build path won. Here is why — phrased the way a VP would hear it when asked to justify the decision.

The Vendor Landscape

Commercial VTO vendors are not cheap. The pricing evaluated in 2024-2025 ranged from $20,000 to $50,000 per year for SDK licenses, with per-session fees on top for high-volume deployments. Some vendors required multi-year commitments. Most restricted which surfaces could ship — web only, or native app only, or kiosk only with an additional license tier.

For a VC-backed D2C brand doing $50M in revenue, that is a rounding error. For an independent optical retailer doing $800K annually, it is a non-starter. EyeBrowse's entire value proposition is making enterprise-grade technology accessible to shops that cannot justify enterprise-grade costs. If the AR pipeline has a $30K/yr floor before a single customer tries on a frame, the unit economics do not work.

That killed the vendor path before any technology evaluation began.

Privacy: The Liability You Don't See on the Invoice

Most technical evaluations miss this: every commercial VTO vendor processes face data on their servers. The customer's webcam feed — or extracted face geometry — leaves the browser, hits the vendor's API, gets processed, and comes back with the frame overlay applied. Some vendors cache face data for "quality improvement." Some store session metadata. All of them require data processing agreements.

That means:

• HIPAA adjacency. Optical retailers often handle prescription data. The moment face biometrics and prescription data flow through the same vendor pipeline, the conversation requires legal review.
• State privacy laws. Illinois BIPA, Texas CUBI, and Washington's biometric privacy law all have specific provisions about face geometry. A vendor that processes face data is a liability vector that any retail client's attorney will flag.
• Vendor data agreements. Each retailer deploying EyeBrowse would need its own DPA with the VTO vendor, or EyeBrowse would need to act as the data processor on their behalf. Either way, it is legal overhead that scales with every new client.

The MediaPipe pipeline runs entirely in the browser. Face mesh extraction, head pose computation, frame overlay — all of it happens on the customer's device. No face data leaves the browser. No server-side processing. No vendor with a copy of the customers' biometric data.

From a compliance standpoint, that is not an incremental improvement. It is a categorically different risk profile. There is no need to explain BIPA to a retailer in Chicago. No DPAs to maintain. No vendor data retention policies to audit every year. The data never leaves, so there is nothing to regulate.

Explained to a non-technical stakeholder, the line is not "client-side inference." The line is "your customers' face data never leaves their device, so there is nothing for a regulator to ask about." That is the version that matters.

Cost: Open Source Changes the Math

MediaPipe is free. Not "free tier with usage limits" free — actually free. Google open-sourced the FaceMesh model under Apache 2.0. TensorFlow.js, which runs the inference, is also open-source. Three.js, which handles the 3D rendering, is MIT-licensed.

The total licensing cost for EyeBrowse's AR pipeline is $0/year.

That does not mean it was free to build. The 3-layer pipeline — face mesh extraction, head pose computation, and the dual 2D/3D rendering system — took months of focused work. There is real engineering cost in getting 468 face landmarks to translate into stable glasses positioning at 30fps across devices. But that is a one-time development cost that amortizes across every retailer on the platform. The vendor license is a recurring cost that scales linearly with deployment.

Here is the math that drove the decision:

| | Commercial Vendor | Custom Pipeline | |---|---|---| | Year 1 | $30K license + $15K integration | $0 license + ~$40K dev time | | Year 2 | $30K license + $5K maintenance | $0 license + ~$8K maintenance | | Year 3 | $30K license + $5K maintenance | $0 license + ~$8K maintenance | | 3-year total | $115K | $56K | | Per additional retailer | +$5-10K/yr (volume tier) | +$0 |

The crossover happens in year two, and the gap widens with every retailer added to the platform. By retailer number five, the vendor path costs more per year than the entire custom pipeline cost to build.

For a platform business — which is what EyeBrowse is — the custom path is not just cheaper. It is the only path where per-client margin improves as the platform scales. A VP evaluating this should see that line item: "$0 incremental AR cost per new retailer." That is what makes the business model work.

Control: Own the Pipeline, Own the Roadmap

The kiosk mode for EyeBrowse needed the AR pipeline to work offline. Retail WiFi drops during peak hours. If a customer is mid-try-on and the connection dies, the experience cannot break. That meant the face mesh model had to be cached in a service worker, the rendering pipeline had to run entirely on the device, and the system needed graceful degradation when connectivity is intermittent.

With a commercial vendor, that feature request is a contract renegotiation. Their SDK probably does not support offline mode. If it does, it is an enterprise tier with a different price point. Either way, the roadmap belongs to them.

Because the pipeline is owned end-to-end, offline kiosk mode shipped in a week. The face mesh model was already cached on first load. The rendering pipeline was already client-side. The encrypted offline order queue (AES-256-GCM, IndexedDB, service worker sync — covered in a separate post about that architecture) plugged in cleanly, and the kiosk was production-ready.

That same ownership enabled other features that a vendor SDK would have made difficult or impossible:

• Custom PD measurement. An iris-diameter calibration system measures pupillary distance from the webcam feed. The average human iris is 11.7mm; MediaPipe gives 5 landmark points per iris. The system computes px-to-mm ratios, captures 9 frames, takes the median, and applies lens distortion correction. A vendor SDK gives you their PD measurement or none at all.
• Dual rendering paths. The pipeline supports both 2D image cross-fade (lightweight, works everywhere) and full 3D GLB model rendering (photorealistic, requires WebGL). The system can switch between them per device capability. A vendor locks you into their rendering approach.
• Admin-side try-on. The same pipeline powers a try-on preview in the retailer's admin dashboard, so store owners can see exactly what their customers see when browsing inventory. That is a selling feature that shipped in a day because the pipeline is just a React component under direct control.

The pattern is straightforward: owning the pipeline means every product decision is an engineering decision, not a vendor negotiation. The time from "we need this feature" to "it is built and shipped" is measured in days, not quarters.

Speed: No Download, No Redirect, No Bounce

Commercial VTO solutions typically fall into two categories: native SDKs that require an app download, or web SDKs that phone home to a processing server for each frame.

The app-download path is a conversion killer. Asking a customer to download an app to try on glasses adds friction that most users will not tolerate. Mobile app install conversion rates hover around 1-3% for non-essential utilities. That is 97% of potential try-on sessions lost before they start.

The server-processing path adds latency. Each frame goes to the cloud, gets processed, and comes back. Even at 100ms round-trip, that is perceptible lag — the glasses visibly trail the user's head movement. At 200ms, it feels broken. And it is entirely dependent on the user's connection quality, which in a retail environment means it is dependent on that router behind the break room microwave.

MediaPipe runs inference in the browser at 30fps on a modern phone. The face mesh model is approximately 2.5MB, loaded once and cached. After initial load, the pipeline is fully local — no network dependency, no latency, no server costs scaling with usage.

The business translation: a customer visits the EyeBrowse storefront, clicks "Try On," and sees glasses on their face within 2-3 seconds of granting camera access. No app download. No redirect to a third-party widget. No loading spinner waiting for a server response. Every second of friction removed increases the probability that a browse becomes a try-on, and every try-on increases the probability of a purchase.

There is no controlled A/B data on this since EyeBrowse was built on the custom pipeline from day one — there was never a vendor version to measure against. The industry numbers cited above (1-3% mobile install conversion, 5-10x funnel uplift from removing an install gate) are directional industry estimates from the broader mobile-conversion literature, not measurements specific to EyeBrowse. They frame the magnitude rather than predict it. For a retailer doing 50 online sessions per day, that order-of-magnitude difference is the difference between roughly 1 try-on and roughly 15.

The Tradeoffs

The custom path has real downsides. Here are the tradeoffs:

Pre-built frame library. Commercial vendors maintain databases of 3D-scanned frames from major manufacturers. The frame asset pipeline had to be built from scratch — photographing frames from multiple angles, processing transparent WebPs, and for the 3D path, creating or sourcing GLB models. This is ongoing operational work that a vendor would handle.

SDK support. When MediaPipe's face mesh detector silently stalls on certain mobile GPUs, that bug belongs to the team that owns the pipeline. A 2-second watchdog timer detects stalls and retries initialization, because roughly 8% of mobile sessions would hang without it. A vendor would (theoretically) handle that, though in practice vendor SDKs have their own device-specific bugs that you cannot fix because you do not own the code.

Development time. The initial pipeline took months of R&D. Head pose computation from flat landmarks, temple arm fade shaders, directional image cross-fade blending — none of this is trivial. The shipped version uses a 2D heuristic for yaw that is technically less accurate than the full 3D computation because it looks more natural. That kind of perceptual tuning takes time that a vendor has already invested.

These are real costs. But they are one-time costs or manageable ongoing costs, paid in engineering time rather than recurring license fees that retail clients cannot absorb.

The Decision Framework

Generalized, the framework looks like this:

Buy when the capability is commoditized, the differentiation is elsewhere, and the vendor cost is immaterial to the unit economics. For a $100M e-commerce company where AR try-on is a nice-to-have feature, license a vendor. The engineering team's time is better spent on the core product.

Build when the capability IS the product, the target market cannot absorb vendor costs, and deployment flexibility is something the vendor cannot offer. EyeBrowse hit all three: AR try-on is the core value proposition, independent retailers need $0 incremental cost per deployment, and kiosk/storefront/admin all need the same pipeline in different contexts.

The mistake most often seen is treating build-vs-buy as a purely technical evaluation. "Which SDK has better face tracking?" is the wrong question. The right questions are: What does this cost the customer? What liability does this create? What product decisions does this constrain? How does this affect unit economics at scale?

Every technical decision is a business decision. The build-vs-buy call on EyeBrowse's AR pipeline shaped the entire product — its pricing model, its compliance posture, its deployment flexibility, and its roadmap velocity. The call holds up.