How I Built a Polymarket Trading Bot With Claude Code, Start to Finish

Most people who watch a build like this focus on the trading angle. That is the least interesting part. The method is the product. I am Madhuranjan Kumar, and I want to be precise about that from the first sentence, because the temptation to evaluate this project on its P&L at hour two misses what it actually demonstrates: a repeatable, five-step workflow for turning a messy idea into a tested, running system, using a coding agent and a clear set of habits that transfer unchanged to almost any business problem you can name.

The trading experiment ran on Polymarket, targeting the Bitcoin up-or-down market that resolves every five minutes. The starting stake was thirty dollars of USDC.e. After two hours the balance had crept to approximately thirty-four dollars with no losing trades yet. I am blunt about this: one bad market window could erase that easily, and this was learning and experimentation, not a financial plan. What cannot be reversed, and what transfers to every business problem in the rest of this piece, is the method that got a working, real-money trading bot from an empty folder to a live Bloomberg-style dashboard in a single afternoon.

The trading angle is the flashiest thing about this project and the least transferable part

Prediction markets are extreme by design. The five-minute resolution cadence means the system makes decisions and sees outcomes at a pace that makes every flaw in the architecture visible within an hour rather than a week. That speed is pedagogically useful. It compresses the feedback loop that would normally take days or months in a business application into something you can observe in real time, which is why the trading example teaches the mechanics faster than a polite business case study would.

But the specifics of late-window scalping on a crypto prediction market transfer to essentially zero other situations. The strategy, buying a position once one side has already moved above 0.9 and holding to resolution without attempting to predict direction, is a function of the peculiar math of that specific market. Apply it anywhere else and it fails. The underlying method that produced the strategy, feeding the agent real documentation, keeping credentials in an env file, sending parallel sub-agents to study public behavioral data, dry-running before going live, and building a dashboard to observe what the system actually does, that method is entirely portable.

The framing that unlocks the value of this build for a business that has no interest in prediction markets is this: anywhere you have a repetitive decision or monitoring process, real data to study, and a clear outcome to optimize, the same five-step loop produces a working tool. The examples later in this piece will be specific about that.

Feeding the agent real documentation is the single habit that separates working builds from broken ones

The most common failure in AI-assisted software builds is asking the agent to write code against a system it has to guess at. The agent's training data contains some knowledge of common APIs, but that knowledge has a cutoff date, may cover only popular versions, and misses entirely any API that is private, newly released, or unusual in its design. When the agent guesses at an endpoint structure and gets it wrong, the code looks correct, compiles without errors, and fails at runtime in ways that are difficult to diagnose without knowing what the real API actually expects.

The fix is simple and should be the first action of every build: create a docs file, paste in the actual API documentation for every external system the code will touch, and tell the agent to read that file before writing any integration code. In this build that meant opening Polymarket's Gamma API quick-start documentation, copying the authentication flow, the endpoint list, the request format, and the relevant response fields, and pasting them into a file called polymarket.md in the project folder. Before the agent wrote a line of integration code, it read that file. Every endpoint it called was built against the actual spec rather than a guess.

This habit costs about five minutes at the start of a build and prevents hours of debugging later. It applies identically to any external system: a carrier API, an agency management system export format, a CRM webhook schema, a marketplace integration. Real documentation in a file the agent reads is the single habit that most reliably separates builds that work from builds that produce code which looks right and fails in production.

Parallel sub-agents studying public data is the capability that changes what any business can research

Because the Polygon blockchain is a public record, every trade made by every wallet is available for anyone to study. This means a profitable trader's strategy can be reverse-engineered from the public data, not from their explanation of what they do but from the actual sequence of positions, sizes, timing, and outcomes that their wallet produced over time. I pointed the agent at a top trader's wallet address and set parallel sub-agents to study the on-chain history in the background while other parts of the build continued in the foreground.

After roughly ten to fifteen minutes the sub-agents returned a concrete plan. The finding was not what most people would predict. The profitable trader was not predicting direction. The strategy was late-window scalping: buying only once one side of the market had already moved above 0.9, holding every position to resolution rather than closing early to avoid additional fees, and repeating this pattern at high volume across many markets simultaneously. The edge was not information about Bitcoin price direction. The edge was about market mechanics at specific probability thresholds near resolution time.

The mechanism that made this research possible, sending parallel agents to study a public data source and return a synthesized plan, is exactly the mechanism that makes the following business applications viable. An insurance agency can send sub-agents to study its own historical lapse data and identify which policy types and premium tiers produced the highest lapse rate in the twelve months before each lapse. A recruiting firm can study the public career histories of candidates who turned down offers and identify the patterns that predicted the rejection. A retail business can study its own transaction records and identify the purchase sequences that consistently preceded high-value repeat customers. In every case the process is the same: identify the public or internal data that holds a behavioral signal, send sub-agents to study it, and read the synthesized plan they return before trusting any of it.

The parallel aspect matters in practice. Sub-agents studying the trading history, the market mechanics documentation, and the competitive context simultaneously finish in roughly the same time as one agent studying one source sequentially. That parallelism is what makes research-heavy builds feasible in an afternoon rather than requiring days of careful step-by-step investigation.

The dry run is not a precaution; it is the step that finds the silent failure before it costs you anything real

A dry run is a full execution of the system against real conditions, with every action replaced by a log entry rather than an actual operation. The bot reads the market, evaluates the strategy, decides to place an order, and then, instead of placing it, writes a log line that says: would have placed this order at this price for this size at this time. The rest of the system behaves exactly as it would in production. The decision logic runs. The timing logic runs. The position management logic runs. Everything runs except the actual external action.

In this build the dry run caught a critical silent failure that would have made every live trade fail quietly without any visible error. The Polymarket exchange requires USDC token allowance to be explicitly approved on the smart contract before any order can be filled. Without that approval, a placed order simply does not fill, and the system receives no error message indicating why. An operator watching the live system would see the orders being placed and no fills occurring, with no indication from the system itself that the missing allowance was the cause. The dry run surfaced this because the log showed the order-placement logic executing correctly while the fills never appeared, which pointed immediately to a step in the setup process that had been missed.

The fix took about thirty seconds: sign the allowance transaction on the exchange, enable token spending, and run the dry run again to confirm fills now appeared as expected. Without the dry run, this silent failure would have appeared only after real capital was committed, real orders were placed, and real time had passed with no fills and no obvious explanation.

Every automated system that touches real money, real customer data, or real external services has at least one silent failure mode of this type. A field name mismatch that causes every age calculation to fail quietly and produce wrong results without an error. An authentication token that expires mid-run and causes every API call to fail with a generic error rather than a clear credential message. A date format difference between two systems that corrupts every comparison without raising an exception. The dry run finds these before they cost anything. Skipping it means discovering them in production, where the cost is real and the diagnosis is harder.

Where this same method lands when you replace prediction market with your actual business problem

The five-step method is: paste real documentation into a file the agent reads first; store every credential in an env file and tell the agent explicitly never to print or log them; send parallel sub-agents to study the data that holds the behavioral signal relevant to your objective; dry-run against non-production conditions to find the silent failures before they matter; build a dashboard so the running system is observable rather than a black box.

Apply that method to an insurance agency's renewal problem and the result is a renewal-risk dashboard that ranks active policies by lapse risk based on the specific signals the agency's own historical data identifies as predictive. The carrier API documentation and the agency management system export format go into a docs file at the start of the build. Every credential for the carrier system goes into an env file. Sub-agents study last year's lapse records, segmented by policy type and premium tier, and return a risk model expressed as a set of conditions the dashboard evaluates against each active renewal. A dry run against a copy of the production data surfaces a date format mismatch that would have corrupted every age calculation in the real system. The fix takes a few minutes. The dashboard then runs against live data, showing active renewals ranked by risk score, flagging the policies that cross the threshold, and surfacing them to the producer's attention before the renewal date, not after the policy lapses.

The difference between this dashboard and a generic CRM renewal reminder is specificity. A generic reminder fires on every renewal at the same interval regardless of any signal. The tailored dashboard shows the producer which client to call today, with the specific context that makes the policy at risk, so the conversation has a purpose rather than being a routine check-in the producer and client both know is not urgent.

Here is the specific number: an insurance agency that catches one additional renewal per month that would otherwise have lapsed, with an average commission of eight hundred dollars, recovers nine thousand six hundred dollars per year. The build cost is one focused weekend. The ongoing cost is the coding agent subscription and whatever compute runs the scheduled data pull. That is the return calculation for the method, applied to one business problem in one industry. The same calculation applies to any industry where a monitoring or decision-support tool, built against the actual data rather than a generic template, produces one additional desirable outcome per month that would otherwise have been missed.

The method is not the trading. The trading is the demonstration. The method is five steps, documented above, and the most important one is the first: give the agent the real documentation before it writes anything. Everything else builds on that.