Tryo

Meet had the business model. I needed to build everything.

Tryo flips e-commerce: customers order up to 10 items with zero payment, a rider delivers in 60 minutes, they try everything on, keep what fits, return the rest to the same rider, and pay only for what they're keeping. Sounds simple. The tech behind it is anything but.

Meet had the business model but no tech, no team, and no product. I joined as fractional CTO to build the entire thing from zero.

I hired 4-5 engineers from scratch and shipped a working product in weeks

No codebase, no engineers, no infrastructure. I hired a team of 4-5 engineers, set up engineering practices, and started shipping: consumer app for browsing and scheduling, rider app for fulfillment, and a backend orchestrating everything.

Try-before-you-buy creates complexity no standard shopping platform can handle. An order is placed, items are physically locked in a specific spot in a specific warehouse, a rider picks them up, the customer tries them at the door, keeps some, rejects others, pays for what's kept, and rejected items need to be sellable again within the hour. All tracked in real time, all synced with Shopify.

I built a system that tracks every single item down to which exact shelf it sits on in which warehouse

Most e-commerce backends track inventory as abstract numbers. "47 units in stock." Useless when a rider needs to physically grab a specific shirt from a specific shelf and deliver it in 60 minutes.

I built what we call bin-level inventory tracking, meaning the system knows exactly where every single item sits, down to the specific shelf in the specific warehouse. Adding an item to cart locks the physical item in its physical location. Every movement is logged in a detailed ledger: stock added, items held for order, items released when rejected, items returned to vendor. The system knows where every piece of clothing is at every moment.

The rider delivers and picks up returns in the same 60-minute trip. I built the engine that makes that work.

Normal delivery goes one direction. Tryo goes both ways in the same 60-minute window with the same rider.

I built a dispatch system tracking 6 steps per order: delivery started, items picked up from warehouse, rider reaches customer, keep/return decision, payment confirmed, items returned to warehouse. Each step triggers backend actions: inventory locks, payment calculations, Shopify syncs, putting items back on the right shelf.

The rider app is a mobile checkout counter: delivery, doorstep try-on guidance, dynamic payment link generation (with discounts, referral credits, Tryo Cash), and return pickup. Rejected items are back on the shelf within the hour. Traditional e-commerce returns take weeks.

We scaled to multiple warehouses. I built the system that decides which one fulfills each order.

As Tryo scaled across Bangalore with multiple warehouses, each serving specific neighborhoods, the routing problem got hard. Which warehouse fulfills which order? How to balance inventory across locations? What about orders spanning two warehouses?

I built the routing and optimization layer. Orders route to the nearest warehouse with available stock. The system balances load, handles edge cases, and optimizes rider routes. This scaled us from early orders to 10,000 orders a month, every one under 60 minutes.

We use Shopify for the storefront, but try-before-you-buy breaks every assumption Shopify makes. I built the bridge.

Tryo uses Shopify for the storefront and financial records, but Shopify can't handle try-before-you-buy natively. I built a two-way sync engine: when a customer keeps 2 items out of 5, the system creates the correct Shopify order, applies discounts, processes partial refunds, and puts returned items back in stock. All automatically in the background so it doesn't slow down the customer experience.

A parallel shopping engine using Shopify as record-keeper with custom fulfillment logic underneath.

Results

Tech Stack