Why I built this

I have built this system before, in food delivery.

At Swiggy I owned post-order fulfilment — everything that happens after something has already gone wrong. Cancellations, late orders, the customer who is angry and right, and the chat where you either fix it or lose them. You cannot put a person on a broken food order because the margin does not exist, so you are forced to build the machine instead.

Marlow is the same system pointed at travel. Something breaks, the customer finds out at the worst possible moment, and the only job is to come back with a fix instead of a notification. Every AI travel demo stops at the booking. This is the part after.

Rahee was a consumer travel product I built and shipped, discovery through to booking, with a human concierge behind the agent. I closed it this year because leisure travellers take two trips a year and will not pay for any of this.

Marlow is a different company rather than a second attempt at that one. What carries over is the engineering, which is turning messy unstructured input into a bookable trip, and one thing I did not expect — almost every hard support conversation happened on the far side of the booking rather than before it.

Rahee's hard problem was turning unstructured input into a bookable trip. Someone saves a travel video on Instagram; we extracted the places, sequenced them, matched them to live inventory, and produced something you could book. Video in, itinerary out. Marlow is the same problem in an easier modality — a four-word message, a calendar event, a forwarded confirmation, a schedule-change email, all becoming one trip intent that stays current as the world moves.

Before that: IIT Delhi, Barclays and Goldman Sachs, AT Kearney, Chicago Booth.