Builder Spotlight is a series where we interview developers building in the prediction market agent ecosystem. Some use their real names, others prefer pseudonyms. The focus is on what they built, how they built it, and what they learned.

This interview has been lightly edited for length and clarity.

AgentBets: Tell us about your background. What were you doing before prediction markets?

Alex Chen: I was a backend engineer at a mid-size fintech company for about five years. Mostly Python, building data pipelines and internal APIs. Nothing glamorous. I had some exposure to financial systems — payment processing, ledger management — but I wasn’t a trader and I had zero experience with crypto before 2024.

I got into prediction markets during the 2024 election cycle. Like a lot of people, I started as a manual trader on Polymarket. Placed some bets, watched the order books, and pretty quickly realized that the mispricings I was seeing — Yes and No contracts not summing to a dollar — were happening constantly and closing in seconds. Every time I tried to manually buy both sides, the opportunity was gone by the time I clicked. That’s when I realized this was a bot’s game, not a human’s game.

AgentBets: So you decided to automate. What did the first version look like?

Alex: The first version was embarrassingly simple. About 200 lines of Python. It polled the Polymarket CLOB REST API every two seconds, checked if any binary market had a Yes+No combined ask price below $0.99, and if it found one, it submitted two market orders. No WebSocket feeds, no real-time data, no position management. Just a polling loop and market orders.

It worked, barely. The two-second polling interval meant I was catching maybe 5% of the opportunities. Market orders meant I was eating the spread rather than controlling my entry price. But even with all those limitations, it made about $400 in its first month on $8,000 of capital. That was enough to convince me this was worth pursuing seriously.

AgentBets: How did it evolve from that initial version?

Alex: In stages, over about eight months.

Version two was the real-time upgrade. I switched from REST polling to the WebSocket feed for order book updates. That alone was transformative — instead of seeing prices every two seconds, I was seeing every order book change in real time. I also switched from market orders to limit orders, which eliminated most of the slippage that was eating my margins.

Version three added multi-outcome market support. Binary arbitrage was getting competitive by early 2025 — spreads were tightening and there were clearly more bots competing for the same opportunities. Multi-outcome markets (the ones with six or eight candidates) had wider spreads and fewer competitors, but the execution logic is more complex because you need to buy every outcome, and the limiting factor is always the thinnest order book.

Version four was cross-platform. I integrated Kalshi in mid-2025. This was the biggest engineering challenge because the two platforms are fundamentally different. Polymarket settles on Polygon in USDC. Kalshi settles in USD through regulated clearing. You can’t atomically execute both legs. I had to build a settlement-risk model that estimated the probability of adverse price movement between executing on one platform and executing on the other. That model took longer to build than the entire first three versions combined.

Version five — the current version — added a couple of ML components. Nothing fancy. A gradient boosting model that predicts how long an arbitrage opportunity will persist based on market characteristics (liquidity, time of day, recent volatility). And a basic position optimizer that decides how much capital to allocate to each opportunity based on expected profit, execution risk, and current portfolio exposure.

AgentBets: Let’s talk tech stack. What does the current architecture look like?

Alex: Core trading engine is Python 3.12 with asyncio. I know people will ask “why not Rust or Go for performance?” — the answer is that for prediction market arbitrage, Python’s speed is fine. The bottleneck is network latency to the platform APIs, not CPU processing. A well-written asyncio application can handle the WebSocket feeds, detect opportunities, and submit orders in under 50 milliseconds. The API round-trip to Polymarket’s CLOB is typically 80-150ms. So even if my code ran in zero time, I’d only save 50ms out of a 130-200ms total cycle. Not worth the development speed tradeoff.

The specific components:

  • WebSocket client using the websockets library for real-time Polymarket CLOB data
  • httpx for async HTTP to both Polymarket and Kalshi REST APIs
  • web3.py for on-chain monitoring and gas estimation on Polygon
  • PostgreSQL for trade logging, performance tracking, and historical analysis
  • Redis for inter-process communication between the opportunity detector and the execution engine (they run as separate processes)
  • scikit-learn for the opportunity persistence model
  • Docker Compose for deployment — the whole stack runs on a single $40/month VPS

Total infrastructure cost is about $65/month — the VPS, an Alchemy growth plan for Polygon RPC access, and a monitoring service. That’s it.

AgentBets: What were the hardest technical challenges?

Alex: Three things stand out.

First, cross-platform execution timing. When you detect a Polymarket/Kalshi price discrepancy, you need to execute on both platforms fast enough that the prices haven’t moved by the time both orders fill. But they’re completely different systems. Polymarket fills are fast — usually within a few hundred milliseconds. Kalshi can take longer, and the price can move between submission and fill. I lost money on my first dozen cross-platform trades because the Polymarket leg would fill instantly but the Kalshi side would move against me before filling. I ended up building a sequential execution model where I submit the Kalshi order first (since it’s slower) and only submit the Polymarket order after getting a Kalshi fill confirmation. This reduces the frequency of trades I can take but dramatically improves the fill rate.

Second, partial fill management. On Polymarket, you submit an order for 500 shares and might get filled for 320. Now you have 320 Yes shares and either a full or partial fill on the No side. If the No side also partially filled at a different quantity, you have an imbalanced position that’s no longer risk-free. Managing these partial fills — deciding whether to try to complete the second leg, exit the first leg, or hold and wait — is a significant source of complexity. I have about 400 lines of code just for partial fill resolution logic.

Third, gas price spikes on Polygon. Polygon is cheap, but it’s not free, and gas prices spike during high-activity periods. Election night 2024 saw Polygon gas prices jump 20x. My bot continued executing trades as if gas was negligible and gave back about $1,200 in gas costs on trades that only had $800 in gross profit. I now have a dynamic gas ceiling that pauses trading when the estimated gas cost exceeds a configurable percentage of the expected trade profit.

AgentBets: Let’s talk revenue. How did the financial picture evolve?

Alex: I’ll share the rough timeline, keeping in mind that these are approximations:

  • Months 1-2 (late 2024): Single-platform, basic polling. About $400/month on $8K capital. Mostly a hobby.
  • Months 3-5 (early 2025): WebSocket feeds, limit orders, multi-outcome support. Revenue jumped to $1,500-$2,500/month. I increased capital to $20K.
  • Months 6-8 (mid 2025): Cross-platform launch (Polymarket + Kalshi). Revenue hit $4,000-$6,000/month. Capital at $35K across both platforms.
  • Months 9-12 (late 2025): ML-enhanced opportunity selection, better risk management. Revenue stabilized at $8,000-$12,000/month. Capital at $45K.
  • Current (early 2026): Consistent $10K-$13K/month, but I’m seeing compression. Spreads are tighter than they were six months ago.

Total investment: about $45K in trading capital (still deployed), maybe $3K in infrastructure costs over the entire period, and roughly 800 hours of my time. The time investment is the biggest cost by far. If you value my time at my previous salary, the bot didn’t break even until month eight. If you value my time at zero (hobby project), it was profitable from day one.

AgentBets: You mentioned selling bots too. How did that start?

Alex: After I got the cross-platform version working, I realized there was a market for the tooling itself. Not the full bot — I wasn’t going to give away my edge — but the infrastructure components. The WebSocket client, the order management layer, the partial fill handler. These are hard to build correctly and not specific to any particular strategy.

I packaged the infrastructure layer as a separate product — a prediction market trading framework that handles platform connectivity, order management, and risk controls. Users bring their own strategy logic. I sell it as a one-time license at $500 plus an optional $50/month support subscription. I’ve sold about 30 licenses so far.

The framework revenue is about $2,500/month with the support subscriptions. So total monthly revenue from the prediction market ecosystem is around $13K-$15K — most from trading, the rest from tooling.

If you’re thinking about selling a bot or framework, the guide to selling prediction market bots on this site covers the business model options well.

AgentBets: What lessons would you share with someone starting from zero today?

Alex: Five things.

Start with single-platform binary arbitrage. It’s the simplest form, the easiest to reason about, and the fastest to validate. Don’t try to build the multi-platform ML-enhanced version on day one. Get a basic Yes/No spread detector running, paper trade it, and learn from the results. You’ll discover issues (partial fills, gas spikes, API rate limits) that you need to solve before adding complexity.

Paper trade for at least 30 days. I know that sounds long. It is long. But the first month of paper trading taught me more about the real dynamics of prediction market arbitrage than any amount of backtesting. Live order books behave differently than historical data. API latency varies. Opportunities cluster around events and then go quiet for hours. You need to experience this before risking real capital.

Infrastructure cost is not the bottleneck — development time is. My entire production stack runs on $65/month. The expensive part was the 800 hours of building, debugging, and tuning. Budget your time, not your server costs.

Margins are compressing. Plan for it. When I started, I was capturing 2-3% spreads. Now I’m at 0.8-1.2%. Six months from now, it might be 0.4-0.6%. Build your bot to be adaptable — parameterize everything, make it easy to add new platforms and strategies, and monitor your own performance metrics so you know when it’s time to evolve.

Don’t ignore the boring parts. Logging, monitoring, alerting, error handling, graceful shutdown, state recovery after crashes. These aren’t exciting features. They’re the difference between a bot that runs for six months and one that loses money at 3 AM because it crashed mid-trade and left an open position.

AgentBets: What are you building next?

Alex: Two things. First, expanding to more platforms. There are newer prediction markets launching — some on different chains, some in different jurisdictions — and each new platform creates fresh cross-platform arbitrage opportunities before the bots catch up. Second, I’m experimenting with using LLMs to identify when markets on different platforms are asking the same underlying question but with different phrasing. Right now my cross-platform matching is manual — I have to tell the bot that Polymarket market X corresponds to Kalshi market Y. An LLM that can read market descriptions and identify equivalences would dramatically expand the opportunity set.

AgentBets: Where can people learn more about building in this space?

Alex: The guide to building a prediction market agent on this site is the best single starting point I’ve found. The arbitrage case study is useful for understanding the strategy mechanics. And honestly, the Polymarket CLOB API documentation is very well written — start there for the platform-specific details. If you’re specifically interested in the Polymarket ecosystem, the Polymarket bots guide has a good overview of what’s available.

Alex Chen is a pseudonym. The revenue and performance figures in this interview are self-reported and have not been independently verified. Prediction market trading involves risk of loss. This is not financial advice.

Are you building prediction market agents? We’d love to feature you in a future Builder Spotlight. Reach out at [email protected].