Most of the ventures on this site are businesses I founded and run. RaftingX is different, and the difference is the point of this essay. RaftingX is a booking marketplace for Ganga river rafting in Rishikesh, founded and run by Amit — a founder with the river in his blood and his team on the ground. I'm a minority partner. I don't run it, I don't front it, and my name isn't on the door. I backed it. Here is why, and what backing it taught me about where my own thesis shows up in the physical world.
A Founder, Not an Idea
I didn't evaluate a pitch deck. I watched a person. Amit knows the Rishikesh rafting economy the way you can only know something you live inside: the operators, the stretches of river, the seasons, the safety culture, what a fair price looks like and who quietly isn't running one. That knowledge doesn't transfer through a slide. It is exactly the asset I can't build with software — and exactly the asset most technology people discount because it doesn't look like technology. When I say I back founders, I mean this: I back domain depth that I could never replicate, and I bring the part he shouldn't have to build alone.
The Trust Gap in Adventure Travel
River rafting in Rishikesh is a real market with a structural trust problem. A traveller booking from five hundred kilometres away can't tell a professional operator from an improvised one. Prices float depending on who's asking. Confirmations are a phone call and a promise. None of this is because the operators are bad — most are excellent — it's because the market has no shared trust layer: no common place where verification, pricing, and confirmation live. Fragmented markets don't lack customers or supply. They lack the infrastructure that lets strangers transact with confidence. That gap is fixable with software, and it's the same gap I write about everywhere else — worn as a life jacket instead of an API.
What "Minority Partner Supporting Technology and Growth" Actually Means
Concretely: the platform — the marketplace, booking flow, and operator tooling — was delivered by my services company, IOanyT Innovations, as an engineering engagement (the case study is public). Beyond the build, I support the growth engineering: search presence, content, conversion, measurement. What I don't do is run the business. Amit and his team operate it — the operators, the trips, the customers, the river. The clean division matters more than people expect: he owns everything that requires being there; I support what can be done from a keyboard. The moment a backer starts acting like a founder, both jobs get done badly.
Verified Operators as a Dependency Layer
The part of RaftingX I find intellectually satisfying is how literally it embodies the dependency layer. The marketplace's real product isn't listings — it's verification: verified operators, transparent prices, confirmed bookings that get checked at the put-in point before a raft touches water. Take the software away and the rafting still exists; take the trust away and the market barely does. That's the thesis I make about AI agents — that value accrues to the layer that makes transactions trustworthy — at national scale, playing out on one river. It convinced me the thesis isn't an AI story. It's an economy story that AI happens to accelerate.
What I Look For Before I Back a Founder
RaftingX set my template, and it has three parts. First, domain depth I can't fake — the founder must know things about their market that no amount of my research would surface. Second, a trust gap software can close — not "an app for X," but a market where verification, pricing, or confirmation is structurally broken. Third, a founder who wants a partner, not a boss — someone who will own the business completely and use what I bring rather than defer to it. Notice what's absent: market size. A founder with depth in a "small" market beats a stranger to a large one, every time I've seen it tested.
If You're Building Something
I keep this lane deliberately narrow — the portfolio I run myself takes most of my hours. But if you're a founder with real domain depth staring at a trust problem in your market, that's the exact combination I back, and I'd like to hear from you. Tell me what you know that I couldn't learn, and where your market's trust layer is broken — the door is here. And if you just want to see the working example: raftingx.com — Amit's river, running on rails we built together.
Frequently asked
What is RaftingX?
RaftingX (raftingx.com) is a booking marketplace for Ganga river rafting in Rishikesh, India. It connects travellers with verified local rafting operators — transparent pricing, instant confirmation, and verification of the trip itself at the put-in point.
Who founded RaftingX?
RaftingX was founded and is run day-to-day by Amit and his team on the ground in Rishikesh, under Greatwhite Continuum Pvt. Ltd. He is the face and the operator of the business; the river domain knowledge is his.
What is Atin Agarwal's role in RaftingX?
Minority partner, supporting technology and growth. Atin is not the founder and not the operator — the founding team runs the business. His role is the platform, the growth engineering, and the occasional hard question.
Does Atin Agarwal partner with or back founders?
Selectively, yes — founders with real domain depth facing a trust or infrastructure problem that software can fix. RaftingX is the working example. The bar is described in this essay; the door is the contact page.
How do I pitch Atin a partnership?
Through the contact page at atin-agarwal.com/contact/. Lead with your domain depth and the specific trust gap in your market — not with the size of the market.
Related reading
From the same content cluster.
Cluster pillar
RaftingX — in the venture portfolio
Where this one sits: a partner venture, run by its founding team in Rishikesh.
Related post
Why I Built The Heartbeat
The first essay in this venture-origin series — a venture I run; this one is a founder I back.
Related post
India Built UPI. The AI Agent Trust Layer Is Next.
The same trust-infrastructure thesis at national scale.
Glossary
Glossary: Dependency Layer
Canonical definition — trust and verification as the layer value accrues to.
From the book
The AI Agent Economy — Book 1
The full thesis, developed across ten chapters and fifteen falsifiable predictions.