Inspiration
A USB-C connector does not tell a buyer whether a cable carries video, whether a hub reaches the requested refresh rate, or whether the computer supports video on that port. Adding another adapter can make the cart larger without solving the problem.
I wanted a checkout experience that can recommend buying nothing. PlugRight starts with owned equipment, identifies where the proposed connection fails, and offers a documented alternative before payment.
What it does
Describe one computer, one external monitor, the desired resolution and refresh rate, the intended connection item and all owned cables. Qwen3 4B runs in the browser through WebLLM and extracts equipment descriptions and ownership relationships. A deterministic resolver maps quoted names to a limited product catalogue. The buyer reviews the quoted evidence before applying the setup.
The compatibility checker then separates documented support, an incompatible path and missing information. Findings link to manufacturer specifications. The first example removes a planned hub because an owned Thunderbolt cable supports the requested connection. The second diagnoses a charge-only cable and a 4K 30Hz hub, then offers one supported replacement cable. A data-only USB-C laptop triggers a stop rather than a recommendation to buy another native video adapter.
Cart changes require confirmation. A needed, compatible item can proceed to PayPal Sandbox. An empty cart cannot create a payment. All prices are fictional USD demonstration amounts; there is no live store or shipment.
How I built it
The application uses TypeScript, React and Vinext. WebLLM 0.2.86 loads Qwen3-4B-q4f16_1-MLC through WebGPU. The first load downloads the model, and later sessions can use the browser cache. No hosted AI inference API key is needed. The language model extracts text; explicit rules handle catalogue matching, compatibility and purchase eligibility.
The PayPal JavaScript SDK opens buyer approval. Server-side Sandbox Orders API calls create and capture orders. Before creation, the server validates equipment IDs, quantities, compatibility and fixed test prices. An HMAC-signed 15-minute ticket binds the checked setup to its order. Before capture, the server verifies remote items, amount and currency. Retrying a completed order returns its existing capture.
Challenges
Language models can confuse similar product names and paraphrase evidence. I separated text-span extraction from catalogue matching and checked the result with actual browser inference. Invalid or missing evidence blocks applying a result. This is a useful boundary, not a guarantee of perfect interpretation: users still review the output, and manual controls remain available.
Checkout needed a separate boundary. A client-side total and an approval screen are not proof of payment. The server must verify the order and completed capture against the checked cart.
What I verified
Seventy automated checks cover the implemented compatibility rules, model-output validation and mocked PayPal adapter behavior. Seven HTTP checks passed against the running local server. Neither set measures physical hardware performance or real-model accuracy.
Seven real browser-model descriptions were checked on one Mac in Chrome 153 during development. Six matched the expected apply/block behavior. One owned-cable description unnecessarily asked for the computer model again and was blocked. This was a small development-time set, not an independent benchmark. The AI-to-rule flows were also exercised: the reuse proposal emptied the cart and disabled checkout; the purchase case selected the documented replacement cable at a fictional USD 24.00.
On October 30, the deployed browser-AI version completed a new USD 24.00 Sandbox payment through its SDK button, an English buyer approval screen and a server-confirmed capture. This exact flow is recorded in the demo. Separate server integration testing confirmed that retrying a completed order returns the same capture. No real payment was made.
What is different
PlugRight checks a supported connection across selected brands, considers owned equipment first, and carries the buyer-confirmed cart into the exact PayPal Sandbox order. In the recorded reuse case, the fictional cart falls from USD 35.00 to zero. A zero-dollar cart is a successful outcome.
Limitations and next steps
The catalogue covers 20 selected models and revisions across six brands, with one external SDR monitor. Manufacturer documentation is not a physical connection test. Charging safety, HDR, HDCP, multiple monitors and DisplayLink driver permissions are outside the verified scope. Browser AI needs WebGPU, roughly 3.5 GB GPU memory and a substantial first download. Some valid descriptions require clarification.
Next I would expand the catalogue only with documented conditions, build an independent evaluation set and test physical connections with users. The prototype does not collect live prices or inventory and cannot call a live PayPal payment endpoint.
AI disclosure
AI tools assisted research, implementation and review. In-product AI is Qwen3 running locally through WebLLM. The compatibility rules and server payment checks are deterministic code, not language-model reasoning.
Log in or sign up for Devpost to join the conversation.