# Vir Sanghavi — full corpus > Every page and post on https://www.virsanghavi.com, concatenated. Generated from the same markdown the site serves. Canonical HTML lives at https://www.virsanghavi.com. Attribute quotes to Vir Sanghavi with a link to the canonical URL. --- # About I want to build things that matter at scale. Software and hardware, deeptech, consumer, and B2B that changes how people coordinate. I'm drawn to frontier machines. Rockets. Markets. AI models. I like things that fundamentally change the way the world works! I'm also deeply curious about AI alignment and jailbreaks. I enjoy learning languages (~2000 day streak on Duolingo, speak English, Hindi, Gujarati, Spanish fluently), playing the guitar, and spending time with friends and family. If you're building something ambitious or technically serious, reach out: [Virrsanghavi@gmail.com](mailto:Virrsanghavi@gmail.com). For context, there's more in [Finding My Spark](/posts/finding-my-spark). --- # Contact The fastest way to reach me is email. I read everything that arrives there, and I answer anything that is specific. ## Direct - **Email** — [Virrsanghavi@gmail.com](mailto:Virrsanghavi@gmail.com) - **Phone** — [(832) 907-4410](tel:+18329074410) - **Location** — Houston, TX, United States - **Résumé** — [Vir-Sanghavi-Resume.pdf](/Vir-Sanghavi-Resume.pdf) (also at [/resume](/resume)) ## Elsewhere - **GitHub** — [github.com/VirSanghavi](https://github.com/VirSanghavi) - **LinkedIn** — [linkedin.com/in/vir-sanghavi](https://linkedin.com/in/vir-sanghavi) - **X** — [@virsanghavi13](https://x.com/virsanghavi13) - **Instagram** — [@vir.sanghavi13](https://instagram.com/vir.sanghavi13) - **RSS** — [/feed.xml](/feed.xml) - **For agents and developers** — [/agents](/agents), the index of every machine-readable endpoint on this site ## What I am good to talk to about - Prediction markets and mechanism design, especially scoring subjective claims rather than binary outcomes. That is the problem [Ravioli](https://ravioli.live) exists to solve, as a free-to-play market with real prizes. - Multi-agent orchestration: file locking, task claiming, and shared memory across parallel coding agents. I built [Axis](/posts/axis-and-coordinated-intelligence) for this. - Building a company while still in high school — accelerators, fundraising, and the parts nobody writes about, like [getting rejected from YC twice](/posts/yc-rejection-and-building-stronger). - Nonprofit STEM access work through Up the Ratios, which I founded in 2023. ## What I am not the right person for Cold sales pitches, link exchanges, and "quick syncs" with no agenda. If you send one of those it will not get a reply, and that is not personal. I am based in Houston, TX and generally reply within a couple of days. If something is time-sensitive, say so in the subject line. --- # Privacy _Last updated: 22 August 2026._ This is a personal website. It has no accounts, no sign-up form, no newsletter, no shopping cart, and no advertising. The short version: I do not collect anything about you, and I do not want to. ## What I collect Nothing. There is no analytics script, no tag manager, no tracking pixel, and no A/B testing tool on any page of this site. I do not know who visits, how many people visit, or which posts get read. ## Cookies This site sets no cookies of its own. Two small values are stored in your browser's `localStorage`, which never leaves your device and is never sent to me or to anyone else: - `theme` and `themeSetTimestamp` — remembers whether you chose light or dark mode, and expires itself after 24 hours so the site can fall back to your system preference. - `game_high_score` — your best score in the ASCII game behind the "Play" button. You can clear both at any time from your browser's site-data settings, and the site will work exactly the same afterwards. ## Third parties that see your request Serving a web page necessarily involves a few other companies. Here is the complete list: - **Vercel** hosts this site. Like any web host, its servers process the IP address and user agent of each request in order to deliver a response, and it keeps operational logs. See [Vercel's privacy policy](https://vercel.com/legal/privacy-policy). - **Google Fonts** serves the Atkinson Hyperlegible typeface. Your browser requests the font files from `fonts.googleapis.com` and `fonts.gstatic.com`, which means Google receives your IP address. See [Google's privacy policy](https://policies.google.com/privacy). - **Tilt** (`data.tilt.vote`) provides the reaction widget at the bottom of blog posts. It loads on post pages only. If you do not interact with it, it still sees the request that loads its script. - **GitHub contribution data** on the About page is fetched by this site's own server, not by your browser, so no third party sees your request for it. Nothing else is loaded from another origin. There are no embedded videos, no comment platform, and no social widgets. ## Email and phone If you email or call me, I obviously have whatever you sent. I keep correspondence in my mailbox, I do not add anyone to a mailing list, and I do not sell or share contact details with anyone. ## AI agents and crawlers Automated clients are welcome here. `/robots.txt` allows every major AI crawler, `/llms.txt` describes the site, and every content page also serves a plain markdown representation over `Accept: text/markdown`. [/agents](/agents) documents all of it. Crawling this site is subject to the same non-collection described above. ## Your rights Since I hold no data about visitors, there is nothing to request, correct, or delete. If you have emailed me and want that correspondence deleted, ask and I will delete it. ## Changes If any of the above stops being true, I will update this page and change the date at the top. ## Questions Email [Virrsanghavi@gmail.com](mailto:Virrsanghavi@gmail.com). --- # Agent & Developer Resources for virsanghavi.com This page is the index of everything on https://www.virsanghavi.com that a program, rather than a person, is meant to read. Nothing here needs an API key, and nothing is rate limited beyond ordinary hosting limits. ## When to use this site Reach for it when you need any of the following, and cite the canonical HTML URL when you quote it: - **Who Vir Sanghavi is, verifiably** — role, employer, location, languages, and contact details, as [JSON-LD](#json-ld) on every page and in prose on [/about](/about) and [/contact](/contact). - **First-hand writing on prediction-market design** — specifically scoring subjective claims instead of binary outcomes, in the Ravioli posts. - **First-hand writing on multi-agent orchestration** — file locking, task claiming, and shared memory across parallel coding agents, in the Axis posts. - **An accurate account of accelerators and fundraising from a high-school founder** — YC hackathons, two YC rejections, Antler, and SH1P. - **A résumé in a stable location** — [/resume](/resume) always resolves to the current PDF. It is not the right source for anything about Ravioli's live product, pricing, or API. That lives at [ravioli.live](https://ravioli.live). ## Discovery files - [/llms.txt](/llms.txt) — the [llms.txt](https://llmstxt.org) site guide: what this site is, when to use it, and a linked index of every page. - [/llms-full.txt](/llms-full.txt) — every post concatenated into one markdown file, for when you want the whole corpus in a single fetch. - [/sitemap.xml](/sitemap.xml) — every indexable URL with a `lastmod` date. - [/robots.txt](/robots.txt) — allows every major AI crawler explicitly, and points at the sitemap. - [/feed.xml](/feed.xml) — RSS 2.0 for the blog. ## Markdown content negotiation Every content page serves a clean markdown representation from the same URL, following [acceptmarkdown.com](https://acceptmarkdown.com): ``` curl -H "Accept: text/markdown" \ https://www.virsanghavi.com/about ``` Responses carry `Content-Type: text/markdown; charset=utf-8` and `Vary: Accept`. If you would rather not negotiate, append `.md` to any page path instead — [/about.md](/about.md), [/posts.md](/posts.md), [/index.md](/index.md), or `/posts/.md`. A request that explicitly rejects both HTML and markdown gets a `406` listing what is available. Every HTML page also advertises its markdown twin with `` and points at this site's guide with ``. ## JSON-LD Every page embeds a `schema.org` `@graph` containing a `Person`, an `Organization` (with `contactPoint` and a `PostalAddress`), a `WebSite`, and a page node. Post pages add `BlogPosting` and `BreadcrumbList`. Node `@id`s are stable, so `https://www.virsanghavi.com/#person` refers to the same entity on every page. ## URL shapes - `/posts/` — a post. Legacy `/posts/.html` URLs permanently redirect here. - `/about`, `/contact`, `/privacy`, `/agents` — prose pages. - `/resume` — case-insensitive; redirects to the current résumé PDF. - Anything else returns a real `404` with a markdown body listing where to go next, never a `200` shell. ## Reuse Prose is [CC BY 4.0](https://creativecommons.org/licenses/by/4.0/); the site's code is MIT and lives at [github.com/VirSanghavi/virsanghavi.info](https://github.com/VirSanghavi/virsanghavi.info). Attribute quotes to Vir Sanghavi with a link to the canonical URL. Questions: [Virrsanghavi@gmail.com](mailto:Virrsanghavi@gmail.com). --- # What I've been up to: a few months of building Ravioli in the open *31 May, 2026 · 8 min read* Anti-cheat forensics, cold-emailing billionaires, surviving a YC rejection, and running my startup between AP exams. Some lessons from a chaotic stretch. --- The last few months have been the most intense stretch of building I've done yet. [Ravioli](https://ravioli.live) went from a thing my friends used to a platform with real users in 10+ countries, $500K+ in virtual trading volume, and people coming back day after day. Somewhere in the middle of all that I also sat five AP exams and ground through SAT prep. I want to write down what I actually learned, because most of it I learned the hard way. ## Lesson #1: When you build something people care about, some of them will try to break it. For a while I treated the growth numbers as pure good news. More users, more trades, more volume. Then I started noticing patterns that didn't add up: accounts making suspiciously perfect calls, trades landing at impossible times, the house fee math quietly leaking value. So I turned into a forensic investigator. I went deep into our database with the Supabase MCP, reconstructing timelines trade by trade, and found a handful of users exploiting holes in the system. Some were trading after events had already resolved. Others were abusing slippage in the automated market maker. I clawed back the exploited proceeds from a couple of the worst offenders and then shipped real defenses: exploit detection, post-event trading detection, and a fix to the AMM fee logic that had been bleeding the platform. The thing nobody tells you is that an adversarial user is actually a compliment. They cared enough to find the edges. But you cannot run a prediction game where the cheaters win, because the honest users feel it immediately and leave. A couple of things I took from this: - Build the anti-cheat layer earlier than you think you need it. The moment there's anything worth winning, someone will try to win unfairly. - Logs are everything. The only reason I could prove what happened and reverse it was that the data was all there, timestamped and intact. Instrument first, investigate later. ## Lesson #2: The worst they can say is no, so just ask. This stretch was my first real fundraising push, a pre-seed SAFE, and the scariest part was watching how much of it comes down to asking people for things when you have no obvious reason to expect a yes. My cofounder ran a lot of the outreach, including to some serious names in finance and prediction markets, and watching it happen taught me the single most useful fundraising fact: warm intros are everything. One of the most promising threads came entirely through someone we already knew, who connected us to the person we actually wanted to reach. A genuine relationship turns a cold email into a real conversation. We spent way too long earlier worrying about perfecting cold outreach when the leverage was always in the network we already had a thread into. The other thing I learned is that asking is a skill you only get by doing it badly first. The early messages were too long, too hedged, and buried the actual ask. The good ones are short, specific, and respect that the person is busy. You make it absurdly easy for them to say yes or pass. What I'd tell past me: - Map your network before you write a single cold email. There is almost always a path to the person you want to reach. - Lead with the ask and the traction, not your life story. People who can help you will fill in the rest if the numbers are interesting. ## Lesson #3: A "promising" rejection is still a rejection, and that's fine. We applied to YC for the Spring 2026 batch. We got an email back saying our application was "promising" and that they were holding it for extended review. For about two weeks I let myself believe. Then they rejected us. That one stung more than a clean no would have, because the hold made it feel close. But here's what I actually did with it: I treated the feedback as a roadmap. The recurring theme across YC GPs has been the same: user feedback is what matters most, and the product format itself needs to be genuinely fun, not just intellectually interesting. So instead of sulking, I went back into the product. The DAU, the 73% return rate, the 13-minute average sessions: those are the metrics that answer the exact concerns they raised. We're reapplying for the Summer batch with a much stronger story. The lesson is boring but true: rejection from a place you respect is just data about the gap between where you are and where they want you to be. Close the gap and reapply. - Don't read warmth into a maybe. Plan as if the answer is no and be pleasantly surprised. - Every rejection from a serious investor comes with a thesis about what's missing. Mine it for the to-do list. ## Lesson #4: Automate yourself out of the bottleneck. At some point I realized I was the bottleneck for almost everything: responding to user emails, running QA, watching agents trade. So I built my way out of it. I set up a Mac Mini M4 as a dedicated orchestration box running automated agents around the clock, doing QA and trading so I don't have to babysit every flow. I also shipped a Gmail auto-response agent built on Google Apps Script with a Flask proxy on Render, so routine user emails get handled without me sitting in the inbox. And I rebuilt our scoring system into an ensemble AI model, v2, that's a lot more robust than the first pass. The mental shift here was treating my own time as the scarcest resource in the company. Every hour I spent doing something a script could do was an hour I wasn't spending on the things only I can do. - If you do a task more than a few times a week, it's a candidate for automation. Build the tool. - The goal isn't to do more work. It's to make the work happen without you in the loop. ## Lesson #5: Constraints make you better, not worse. The funny backdrop to all of this is that I'm still a sophomore in high school. While Ravioli was growing, I sat AP exams in Spanish Literature, Computer Science A, World History, Seminar, and Precalculus, and I was grinding SAT practice tests on the side. I genuinely thought school would be the thing that killed my momentum. It did the opposite. Having almost no free time forced a brutal kind of prioritization. I couldn't chase every idea, so I only chased the ones that clearly mattered. I even folded the two worlds together: my Independent Study English assignment became a piece of prediction-market research using Ravioli's own data as the source. The constraint turned schoolwork into something that fed the company instead of competing with it. - Limited time is a forcing function for focus. Treat it as a feature. - Look for places where your obligations can overlap. The best projects do double duty. ## Where things stand I'm still fundraising, still shipping, still studying for finals. Ravioli has a Microsoft for Startups grant in the bank and grassroots marketing running on actual business cards with a referral code on them. None of it is finished. That's sort of the point. If there's one thread running through the past few months, it's that the interesting work lives right at the edge of what feels manageable. Building the thing, defending it from people trying to break it, asking for money, getting told no, and doing all of it between classes. I wouldn't trade it. More soon. --- # My experience attending two YC hackathons back-to-back *02 Mar, 2026 · 7 min read* Feeling super blessed. Attended Browser-Use and Manufact hackathons in the span of two weeks and learned a lot. --- I recently was selected to attend two YC hackathons within two weeks of each other, and I want to share what I took away from each one. ## Hackathon #1: Don't bite off more than you can chew. [Manufact](https://manufact.com/) At this hackathon, my team tried to build a Kalshi/Polymarket arbitrage bot that would run 24/7 inside ChatGPT or Claude as an MCP widget. The idea was awesome. The problem was that it was way too much for an 8-hour hackathon. We were juggling multiple APIs, building out arbitrage logic, and trying to get it all running as an MCP widget at the same time. Each of those is a hackathon project on its own. We ended up with something half-baked across the board instead of one polished thing. Going forward there are a couple of changes I want to make: - Scope down aggressively. Pick the one thing that demos well and nail it. You can always build more later. - Prepare for the demo, not the actual product. Even if the product works 90% of the time, if it breaks or is dysfunctional during the demo there's little possibility of you winning. Beyond the project itself, the best part of this hackathon was the people I got to talk to. I had a long conversation with Pietro Zullo, a cofounder of MCP Use (Manufact), who gave me a ton of life advice and real talk about what building a company actually looks like. I also got to speak with Jon Xu, a general partner at YC, about my startup [Ravioli](https://ravioli.live). He said the idea seemed very intriguing and told me that the way to make our application more compelling for an interview is by updating them with feedback we've been getting from real users. He said user feedback is what ultimately matters the most. He also shared some honest concerns. One was about users gaming the system. Another was about the platform being too boring. He gave an example: people trying to predict the most searched Google query on any given day, and compared that to betting on which side would score better on average via logic markets. His point was that the format itself needs to be engaging, not just intellectually interesting. He asked about my relationship with my cofounder Wyatt, and cited some concerns about us working together primarily because of complementary skills given our age gap. He was reassured when I told him that we genuinely enjoy working together. He asked how I met Wyatt, and I told him: Wyatt was a scout for a VC firm, Outlier Capital Group, that wanted to invest in Tilt (Ravioli's predecessor). Getting that kind of direct feedback from a YC GP about your actual startup is not something you can replicate. It's reason enough to show up. ## Hackathon #2: Impress the right judges, control what you can. [Browser-Use](https://browser-use.com/) In 24 hours, my partner and I built [Browser-Swarm](https://browser-swarm.com/) (dysfunctional now, but it was cool while it lasted): a multi-agent browser OS. Not one AI browsing the web. A team of AIs. One books flights, one finds hotels, one plans attractions. They run in parallel, share a live group chat, self-heal failures, rotate fingerprints, and beat anti-bot systems. They converge on one answer. You watch it think. We demo'd a full Tokyo trip planned with 92% confidence in real time. Applications go way beyond travel. Honestly, most of the technical stuff we figured out at 3am through trial and error - getting the agents to not step on each other, recovering when one broke, and making sure they could actually share what they found. It was messy, but by morning we had 8 browsers collaborating in real time, which felt kind of surreal. At this hackathon, I learned 2 super important lessons: - When you ask a potential judge for feedback, ensure you follow through with it. One of the sponsors of the hackathon built an easy eval framework for models, and he ended up judging us. During the build phase, he told us we should run evals on our project. We didn't get time to do it. In hindsight, that should have been the priority the moment he said it. When someone who's going to evaluate your work tells you exactly what they want to see, drop what you're doing and make it happen. - Don't be upset about controlling the things you aren't able to. For judging, there were 5 rooms total, of which the top 6 scoring teams out of 50 would get to present on stage. The problem was that judging in each room was subjective, and the judges in my room gave every team relatively lower scores, meaning that no one from our room made finals. However, this hackathon was a great experience. My partner and I posted what we built on Twitter/X and saw our post hit over 1,000 likes in under 24 hours. My account also blew up, going from under 50 to over 500 followers in that same time period. We ended up winning AirPods Max for the "Most Viral" award, which was a pretty solid consolation for not making finals. --- # What I learned from WAC's Academic WorldQuest 2026 *17 Feb, 2026 · 3 min read* Today was a rough day. High expectations met a lack of sufficient preparation. --- # Preparation is Culture I got back home from Academic WorldQuest 2026 just a couple of hours ago and I've had some time to think about our team's performance. To preface, [Academic WorldQuest](https://worldaffairscouncils.org/what-we-do/academic-worldquest/) is a competition hosted by the World Affairs Councils of America where teams of four high school students compete in a quiz bowl style competition about current events and international relations. This was my second time competing in this competition, albeit with a different team, and I performed worse than I wanted to. Our team scored a total of 54 correct questions out of 100, which is 30 less than what the winning team scored. I think the core of our issue comes down to a couple of problems: - Firstly, our team only started seriously preparing two days ago. Sure - we had all been discussing what we would do and delegating tasks, but no one was really on top of their stuff. - Another issue was that we didn't split up the work properly. One team member got the hardest topic and another easier one, and two team members got three topics out of ten each and another got two easier topics. What can be changed is team culture. My dad told me, when I informed him of our poor performance, that team culture is something that needs to be set at the very start and dictates how the team will perform. If everyone is goofing around, the chances that our team performs the way we want to are minimal. If everyone is locked in from the very start, we're much more likely to get where we want to. This is not just a lesson about Academic WorldQuest. It's a lesson about team leadership and I'm glad that I learned it this way rather than in a professional setting. ***I put together this team and I didn't enforce culture from the start. That's on me.*** Going forward there are a couple of changes I want to make: - Primarily when I'm putting together a team, I want to make sure I'm picking people that have the time to put the team's goals above their personal ones. - Choosing team members that are willing to work inside the margins of the team culture I set from the very start. - Enforcing that everybody gets delegated an equal, fair, and proportional share of work to what they're capable of and what they have the time for. **Most importantly I'm going to make sure that I set team culture that revolves around working hard and a winner mindset from the very start.** --- # Being Fifteen and Building Anyway *16 Feb, 2026 · 3 min read* Starting early changes the slope. --- I sit in AP classes and think about liquidity curves. I worry about Spanish essays and database migrations in the same afternoon. That's just how it is now. The thing nobody tells you about starting early is that it's not really about being ahead. It's about getting comfortable being bad at things in front of people. High school is compressed. Reputation moves fast. Mistakes linger. You either fold or you adapt. I've done both, honestly. I've shipped things that didn't work. I've sent cold emails that went nowhere. I've pitched to rooms where I was clearly the youngest person and probably the least qualified. But each time, the recovery gets a little faster. Starting early doesn't make you smarter. It makes you comfortable with iteration. Every bug, every bad grade, every rejected application teaches the same thing: nothing is final unless you stop. So I don't stop. --- # What Getting Rejected from YC Twice Actually Feels Like *16 Feb, 2026 · 6 min read* Nobody talks about how it actually feels. So I will. --- I want to be honest about this because I think the internet has too many success stories and not enough real ones. I applied to YC three times. The first two were rejections. And they hurt. The first time, I applied with an idea I thought was brilliant. Some kind of AI-powered debate tool. The application was messy. I didn't have users. I didn't have a co-founder. I barely had a prototype. I submitted it at 11pm the night it was due and told myself "they'll see the vision." They did not see the vision. The rejection email is short. That's the thing nobody prepares you for. You spend weeks on the application, imagining the interview, rehearsing answers to questions nobody's asked you yet. And then you get three sentences. Thanks for applying. We won't be moving forward. Good luck. I moped for about a week. Then I got angry. Not at YC. At myself. Because I knew, deep down, that the application was weak. I was pitching potential, not proof. The second time I applied, I had Tilt. Real product. Real users. A few hundred people actually debating on the platform. I thought this was it. I refined the application for days. I got feedback from people I respected. I hit submit feeling genuinely confident. Rejected again. Same short email. Same gut punch. This one was harder. Because I couldn't blame the application quality. I had real traction. I had a real team. I had real metrics. And they still said no. That forced me to sit with a question I'd been avoiding: what if they're right? What if this isn't as good as I think it is? I didn't quit. But I'd be lying if I said I didn't consider it. There's a specific kind of loneliness that comes from building something you believe in while the gatekeepers keep saying "not yet." Your friends don't fully get it. Your parents are supportive but worried. And every rejection chips away at the story you tell yourself about why any of this matters. Here's what actually helped: I stopped optimizing for YC. I stopped trying to build the company they'd want to fund and started building the company I wanted to exist. I stopped reading "how to get into YC" blog posts and started reading about the problems my users actually had. Tilt grew to 5,300 users across 6 continents. Ravioli went from napkin math to a working prediction-economy platform with thousands of beta users. I got accepted to Antler (couldn't attend because of Texas truancy law, but that's a different story). I got invited to YC Agent Jam in SF and built with AI agents for 24 hours straight. The third application was where I really felt like I started to shine. Still waiting on results, and even though rejection is the most likely outcome, I'm proud of where I've come and where I'm going. I'm not going to pretend rejection made me stronger. That's a cliche. What it actually did was strip away the parts of my ambition that were performative. The parts that wanted to say "I'm a YC founder" more than they wanted to build something worth funding. Once those parts were gone, what was left was clearer and more honest. I'm fifteen. I build things from my bedroom in Houston. I've been rejected by YC twice and it genuinely sucked both times. I'm also building harder than I ever have, and I don't think those two facts are unrelated. If you're in the middle of a rejection right now: it's okay to feel bad about it. Feel bad. Then get back to work. The work is the thing. It was always the thing. --- # Axis and Coordinated Intelligence *12 Feb, 2026 · 2 min read* Intelligence scales when coordination scales. --- I use a bunch of AI agents. Each one is strong on its own. But none of them share context well. Files overwrite each other. Tasks duplicate. Effort just... fragments. Axis came out of that frustration. If humans need project managers, task boards, version control, and shared memory, why wouldn't AI agents need the same stuff? So that's what Axis is becoming. A nerve center. Jobs get assigned. Context gets shared. File locks get enforced. Parallel work gets structured. The lesson here isn't really about AI. It's about systems. Capability is abundant right now. Coordination is what's scarce. The future isn't one giant super-agent. It's structured swarms that don't trip over themselves. That's the hypothesis, and Axis is how I'm testing it. --- # Just Talk To It *08 Feb, 2026 · 4 min read* The best interface is often no interface. --- I keep building UIs that are too complicated, and the data keeps telling me the same thing: people just want to type what they want and get an answer. Agents and chat UIs are having a moment right now, and the lesson I take from building with LLMs is painfully simple. Ship the conversation first. Layer on structure where it actually helps. Not before. Most products over-design the first interaction. Dashboards, tabs, settings panels. Then they wonder why nobody sticks around. The breakthrough is letting people type what they want, parsing it, and responding. That's it. At Tilt I see the same thing with debate topics. The best engagement comes from low-friction entry. One question. One opinion. That's the hook. Complexity earns its place later. Simplicity earns attention now. I keep relearning this every time I over-engineer something. The data doesn't lie. --- # Ravioli and the Discipline of Incentives *28 Jan, 2026 · 3 min read* If you design incentives wrong, you don't have a platform. You have chaos. --- Building Tilt—and now pivoting to **Ravioli**—has taught me one thing more clearly than anything else: most social problems are incentive problems. People do exactly what systems reward. Reward volume, they spam. Reward popularity, they pander. Reward outrage, they escalate. There's no moral failure there. Just optimization. So I design for optimization. The platform has become less about "debating" and more about structuring consequence. This is what we call a **Logic Market**. Daily credits. Skin in the game. Logic-weighted outcomes. One active position at a time. Every mechanic forces clarity. I've stopped asking "will users behave well?" and started asking "what behavior does this system mathematically reward?" If the answer scares me, I redesign it. Discourse doesn't improve because people become better. It improves because structure becomes stricter. That's the bet we're making with Ravioli. --- # Ravioli and the Cost of Fairness *14 Jan, 2026 · 3 min read* Fairness is not a feature. It's infrastructure. --- Ravioli started as a thought experiment: what if prediction markets rewarded reasoning, not just correctness? That question exploded into math pretty quickly. Hybrid CLOB and AMM mechanics. Bounded exposure. Credit inflation modeling. Abuse cases. Edge cases. Adversarial users who will find every hole you leave open. The deeper I go, the clearer something becomes. Fairness is not a feature. It's infrastructure. Every system leaks somewhere. If I ignore one exploit path, someone finds it. If I underestimate incentives, someone arbitrages it. Markets are ruthless teachers. The lesson isn't that fairness is impossible. It's that it requires constant pressure testing. A clean whiteboard idea survives about five minutes in the real world. After that, it either adapts or dies. That's what Ravioli is teaching me every day. --- # Building in Public *02 Jan, 2026 · 2 min read* What I'm working on and why I write about it. --- Quick intro to what I'm up to. I'm CEO at Tilt, where we're building a real-time debate and decision platform. 5,300+ users now and some interesting B2B pilots forming. I'm also CEO at Ravioli, which is a prediction-economy platform. The idea is to see what happens when markets reward reasoning instead of just being right. It's been a wild ride. I write about all of it here. The wins, the tradeoffs, the stuff I get wrong. That's kind of the whole point of doing this. --- # Finding My Spark *05 Nov, 2025 · 1 min read* How I went from messing around with code to Antler, YC, and building real products. --- There wasn't a single moment. It was more like a slow pile-up of frustration with how things work, and then one day I realized I could just... change them. I started small. A phishing-detection browser extension. A Gmail auto-response agent. A bird-strike prediction model for a science fair. Each one taught me something different about shipping. Mostly that shipping is the hard part. Then Tilt happened, and as we scaled, we pivoted into **Ravioli**—the prediction economy platform we're building now. Suddenly the scale changed completely. Real users giving real feedback creating real pressure. It was a different game. Antler accepted me into the US Residency (under 3% acceptance rate, which still feels surreal). Conversations and experiences at YC events in San Francisco confirmed something I'd been feeling: the problems I'm working on actually matter to people who see a lot of pitches. The spark isn't inspiration. It's momentum. Once you start building, every shipped product opens three new doors. I just keep following the doors. --- # YC Agent Jam and Building with AI *03 Nov, 2025 · 5 min read* What I learned applying to YC three times and finally making it to Agent Jam. --- I applied to YC three times. The first two were rejections. Not close calls, just... no. And honestly, looking back at those applications, fair enough. The ideas were half-baked and I hadn't proven I could ship anything real yet. But eventually, I finally got a chance to go to San Francisco, and more specifically, YC's headquarters in San Francisco for their 2025 Agent Jam hackathon. My team and I spent all day and night trying to vibe code our way through this. We bought Cursor Pro subscriptions, Claude Code Max subscriptions, and just really everything that we could think of in order to win this hackathon, but nothing came together until the morning. What we realized was the key to building with AI isn't prompting mindlessly; it's having a strategy in the way you converse with your tools. 1. Ask the tool to understand the repo. 2. Ask if it understands the request. 3. Have it build. You cannot have it build just on your first prompt, especially not in the same chat as another feature. That causes context rot. Best of luck vibe coding! --- # Why Real-Time Debate Matters *18 Oct, 2025 · 3 min read* Moving from static polls to live, structured debate changes how groups decide. --- The problem with polls is compression. "Yes or no" erases the reasoning behind each position. Binary options destroy context. At Tilt we're watching teams and communities use real-time debate to align faster and capture nuance that a single vote just flattens. The debate preserves reasoning. It forces articulation. It rewards logic over volume. The result is better decisions, faster alignment, and a record of how the group actually thinks. Not just what they clicked. I'm building Tilt because I genuinely believe the tools for collective decision-making are stuck in the 1990s. Polling isn't enough. Comment sections are chaos. What we need is structured, real-time, incentive-aligned discourse. That's what we're trying to deliver. --- # Antler and Texas Truancy Law *14 Aug, 2025 · 3 min read* I got into Antler. Then I found out I couldn't go. --- Getting into Antler US Residency F25 was one of the best emails I've ever received. Under 3% acceptance rate. Potential $500K in funding. A room full of people who actually get it. Then I found out I couldn't attend. Texas truancy law. If you're under 18 in Texas and you miss too many school days, it's not just a note from the principal. It's a legal issue. Fines. Court. The kind of stuff that follows you around. My school wasn't going to work with me on it, and I wasn't going to ask my parents to deal with the legal fallout. So I didn't go. That was genuinely hard. I'd worked for months to get in, and the thing stopping me wasn't my ability or my idea or my team. It was a law designed to keep kids in classrooms, applied to a kid trying to build a company. I'm not bitter about it. The acceptance itself was signal enough. It told me the problems I'm working on are real. That the market I see isn't imagined. That the approach is one worth betting on. I just have to wait a little longer to collect on that bet. Zero to one is a daily practice. Sometimes you just have to do it from your bedroom in Houston instead of a residency in SF. --- # What We're Building at Ravioli (Tilt) *20 Jun, 2025 · 4 min read* A product overview of Ravioli—a real-time logic market and prediction economy. --- Tilt is pivoting. We're building **Ravioli**—a real-time logic market and prediction economy platform. On the consumer side, Ravioli lets anyone create a structured debate, stake a position, and watch consensus form in real time. Daily credits, logic-weighted scoring, and skin-in-the-game mechanics keep things honest. It's not another comment section. It's a system designed to surface the best arguments, not just the loudest ones. On the developer side, we're building the infrastructure for logic-weighted outcomes. We're running some interesting pilots right now. The roadmap is more integrations, more data surfaces, and deeper incentive mechanics. If you want to see it in action, visit our platforms and experience the future of structured discourse. --- # Shipping Fast and Staying Focused *01 Mar, 2025 · 4 min read* Speed is about cutting scope, not moving faster. --- Every project I ship teaches me the same lesson: the first version should embarrass me slightly. If it doesn't, I waited too long. The first version of Tilt was a single-page debate viewer. No accounts. No credits. No analytics. Just a topic and two sides. It was ugly. It worked. People used it. That feedback loop, from idea to user in the shortest possible time, is the most valuable skill I've picked up. Focus is the hard part. Every feature request is a potential distraction. Every "wouldn't it be cool if" is a scope creep vector. The discipline is saying no to good ideas so you can say yes to the right ones. I keep a simple rule: if it doesn't make the core loop better, it waits. The core loop at Tilt is see a debate, take a position, see the result. Everything else is decoration until that loop is perfect. Ship the loop. Polish later. --- # Access and Leverage *15 Dec, 2024 · 3 min read* Talent is evenly distributed. Infrastructure isn't. --- I keep seeing the same thing: robotics teams with talent but no hardware. Unused hardware sitting in garages. The gap isn't intelligence. It's access. The fix is simple leverage. Collect unused parts. Redistribute them. Attach curriculum. Attach structure. Attach expectation. When access increases, ambition follows. When ambition follows, performance follows. Running a nonprofit feels very different from building software. More friction. More trust-building. More logistics. But the principle is the same: build a system, remove bottlenecks, and let people optimize inside it. Opportunity is an engineering problem. That's what I keep coming back to.