By Felix – founder of unCoded, trading crypto since 2016.

I've had this conversation probably thirty times in the last eighteen months.

Someone on Twitter or Reddit or at a crypto meetup hears that I run a trading bot platform. They ask what it does. I explain – self-hosted, non-custodial, profit-sharing pricing, tick-based execution. They nod politely.

Then they say some version of the same thing: "But can't you just ask ChatGPT to build you a trading bot in a day? Why would anyone pay for this?"

It's a fair question and it deserves a real answer. Because the surface-level version of that question is correct – you absolutely can get ChatGPT to write something that looks like a trading bot in a few hours. The deeper version of the question is where the honest answer lives, and it's the reason I'm still doing this the hard way after five years while the vibe-coding crowd keeps shipping bots that work for six weeks and then quietly die.

Here's the full answer.

What "just ask GPT to build a bot" actually produces

I've read hundreds of these bots. Reddit and GitHub are full of them. The pattern is always the same.

Someone watches a YouTube tutorial. They ask GPT to write a Python script that connects to Binance, fetches price data, applies an RSI indicator, and buys or sells based on thresholds. A hundred and fifty lines of code later, they have something. They backtest it against last year's BTC data and the return looks incredible. They post it on r/algotrading with a screenshot. Other people upvote. Someone deploys real money.

Six weeks later, the bot is either dead, broken, or slowly bleeding capital in ways the owner doesn't understand yet. Sometimes all three at once.

This isn't because GPT writes bad code. It writes surprisingly good code. This is because writing the first 150 lines of a trading bot is about 2% of the work of building a trading bot. The other 98% is everything that doesn't fit in a Stack Overflow answer or a GPT conversation.

The iceberg

A naive trading bot is the tip of an iceberg. Here's what's actually under the water.

Real error handling. Binance returns error code -1003 for rate limiting, -2010 for insufficient funds, -2011 for order-not-found, -1021 for timestamp desync, -1121 for bad symbol. Each one needs different retry logic. Rate limit errors need exponential backoff. Insufficient fund errors need to reduce order size and retry once. Timestamp errors need to re-sync the system clock. Order-not-found might mean the order was already filled and your internal state is stale. Getting any of these wrong in live trading means you either lose money to bad retries or miss executions you should have caught. GPT will write you a generic try/except that catches all errors and prints them. That's not error handling – that's silence before a crash.

State consistency under network failures. Your bot places an order. The HTTP request times out before the exchange response returns. Did the order succeed? You don't know. If you retry blindly, you might create a duplicate position. If you assume it failed, you might miss a fill that actually happened. The correct answer is idempotency keys, reconciliation loops, and atomic database state transitions – concepts that require distributed systems engineering, not Python syntax. A script asking for "a trading bot" gets none of this.

WebSocket reconnection and state recovery. Your WebSocket disconnects at 3 AM. The default behavior of most code is to reconnect and assume everything is fine. In reality, you missed price updates, trade executions, and balance changes during the disconnect. Your internal state now diverges from the exchange's reality. Every subsequent trade decision is made on corrupt data. Real bots need reconciliation-on-reconnect logic that compares internal state against the exchange and corrects drift. I've never once seen this in a GPT-generated bot.

Timestamp synchronization. Exchanges reject requests where the client timestamp drifts more than a few seconds from server time. Server time changes. Your server clock drifts. Without active time-sync logic, your bot will start rejecting itself in production within days. The generated code doesn't handle this because the tutorial didn't mention it.

Fee accounting in the right asset. Your bot trades BTC/USDT. Fees are paid in BNB for the discount. Profit calculations that treat fees as percentages of USDT trade value are wrong. They need to convert BNB to USDT at each trade's exact timestamp. A GPT-generated bot almost always gets this wrong because the tutorial didn't cover it.

Order minimum filters. Binance enforces NOTIONAL filters – minimum order value in quote currency. LOT_SIZE filters – minimum quantity with specific increments. PRICE_FILTER – tick-size rounding on limit orders. Every exchange has its own version of these. Your strategy calculates "buy 0.00023 BTC at $94,352.41," the exchange rejects it because neither value passes the filter, your strategy thinks it placed the order, and now your state is wrong. Real bots check these filters on every order before placement.

Backtesting that reflects reality. Candle-close evaluation misses stop losses triggered by wicks. Sharpe ratios need different annualization factors for different timeframes. Fees need to be calculated in the asset they're actually paid in. Slippage needs to be modeled. Liquidity assumptions matter on smaller pairs. A GPT-written backtest runs through candles, compares to thresholds, and produces a beautiful number that has no relationship to live performance.

The tick problem. Real trading opportunities happen between polling intervals. If your bot checks price every 30 seconds, you miss everything that happens in the other 29.99 seconds. Real execution requires WebSocket streams, order book processing, and tick-level state management. Writing that is not hard in principle – it's hard because it has to not break under adversarial conditions, which means connection failures, message ordering issues, out-of-order timestamps, exchange maintenance windows, and dozens of edge cases that only emerge in production.

Concurrent strategy execution. One symbol per bot is trivial. Running multiple symbols simultaneously with isolated state, fee accounting per pair, and proper resource limits requires actual software engineering. Race conditions between concurrent positions can produce duplicate orders, missed stops, or corrupted balance calculations. GPT will write you code that works for one pair and breaks silently on two.

Time-weighted position management. Holding a position for 6 hours is different from holding it for 6 days. Strategies that adjust profit targets based on position age, per-split trailing stops, dynamic risk parameters that respond to how long capital has been deployed – these aren't things you can describe to GPT in three sentences because they require trading domain knowledge that isn't in the training data.

Database schema for financial data. Your bot needs to store orders, fills, positions, trades, balances, and their relationships. It needs transactional consistency – either all parts of a state change happen or none do. It needs immutable order history – records of what actually happened cannot be modified later because that would destroy the audit trail you need for tax reporting. ACID guarantees, foreign keys, atomic transactions. Real schema design takes days. GPT will give you a single flat table that falls apart the first time two events happen simultaneously.

I could keep going. This list is maybe 20% of what actually matters.

The vibe-coded version

So what happens when someone ignores all of this and ships a GPT-generated bot?

Week 1: Runs great. Places trades. Dashboard looks good.

Week 2: WebSocket disconnects during a volatile hour. Bot reconnects, continues trading with stale state. Places duplicate orders. User notices but doesn't understand why. Manually cancels the duplicates.

Week 3: Binance rate limits the bot because the error handling retries too aggressively. Some orders don't execute. Backtest showed 100% fill rate. Live performance doesn't match.

Week 4: Stop loss "triggers" during a wick. In backtest the candle closed above the stop so it looks like the position stayed open. In reality it executed at the wick low. User can't reconcile the discrepancy.

Week 5: Server clock drifts. Every API call starts failing with timestamp errors. Bot sits idle for 18 hours before user notices.

Week 6: User rewrites chunks with GPT's help. Introduces a new bug where fee calculations are wrong. Dashboard shows profit. Exchange account shows loss. User doesn't understand why.

Week 7-12: Slow capital bleed from accumulated small errors. User blames the market, the strategy, the exchange. The bot continues "working" in the sense that it's still running. The capital continues leaving.

Month 6: User concludes trading bots don't work and quits. The actual problem was that the bot worked fine for the parts GPT helped with, and failed on the parts GPT couldn't have known about.

This isn't a strawman. This is the modal path for vibe-coded bots. I've watched dozens of people walk through it over the past two years.

Why the hard path still matters

The reason I still build unCoded the hard way isn't that I think vibe-coding is inherently bad. GPT is a genuinely useful tool. I use it for prototyping, for documentation, for exploring ideas quickly.

The reason I still do it the hard way is that real trading software is a specific category of engineering where the failure modes are financial. Code that fails silently in a web app shows a user-visible error and annoys someone. Code that fails silently in a trading bot loses money in ways that accumulate before anyone notices. The debugging happens after capital is already gone.

Most software engineering disciplines have developed practices for managing this kind of risk: ACID databases for financial correctness, atomic state transitions for consistency, reconciliation loops for drift detection, idempotency keys for retry safety, comprehensive error classification for correct recovery, proper backtesting methodology for honest validation. These practices exist because enough people lost enough money figuring out you need them.

A GPT session that's never read a post-mortem of a trading system failure doesn't know about any of this. It will write you code that does what you asked for and nothing more. The things you didn't know to ask about – the 98% of engineering that separates production trading systems from toy scripts – just don't appear in the output.

Why I use my own product

Here's the part that sounds like marketing but is actually important.

I run unCoded on my own capital. Every strategy I deploy goes through the same bot that paying users deploy through. Every bug I find affects my trading before it affects theirs. Every feature I build is a feature I'd want as a trader, because I'm the one using it.

This is structurally different from how most bot platforms work. Most founders of subscription platforms don't actually run their bots on meaningful capital. They might have test accounts. They might have demo configurations. But their income comes from subscription fees, not from trading, so there's no personal cost when the bot fails to execute correctly.

When your income depends on subscription retention, you build toward what keeps users paying. When your trading capital depends on the bot working correctly, you build toward what actually produces returns. These are different products over time.

I could outsource development. I could hire a team of engineers who've never traded and give them specs. I could get something shipped faster. I don't, because the value of the product is precisely the trading-engineering integration – knowing what can go wrong at the trading level because I trade, knowing what can go wrong at the engineering level because I engineer, and building something that handles both because neither half is handled by people who only understand one.

This is the reason vibe-coded bots don't replicate what unCoded does, and it's also the reason most commercial bot platforms don't either. The product is the intersection of two specialties, and most attempts come from someone who has one and not the other.

What you're actually paying for

When someone asks why they'd pay for a trading bot when GPT can write them one, the honest answer is this: you're not paying for the code.

You're paying for the accumulated experience of watching things break in production over years. You're paying for the architectural decisions that came from losing money to race conditions, timing bugs, state corruption, and edge cases that only emerge under specific conditions. You're paying for tests written by someone who knows what to test because they've seen what fails. You're paying for defaults that reflect actual trading lessons rather than what looks reasonable in isolation.

The code itself is the smallest part. It's the wrapper around hundreds of specific engineering choices that were made because something went wrong once. You can't get those from a GPT session, because GPT doesn't know what went wrong in my 2022 or my 2023. You can only get them from someone who was there and wrote code that remembers.

The fair counter-argument

I want to be honest about the other side.

If you're a capable engineer who also trades seriously, and you're willing to spend a year or two rediscovering the lessons I've described, you absolutely can build a bot that works. Freqtrade is open-source proof that engineering-focused traders can build sophisticated tools. People have been doing this for as long as algorithmic trading has existed.

What's different in the GPT era isn't that it's suddenly possible to build a bot – it was always possible. What's different is the marketing of it. "GPT can build you a trading bot in a day" is true in the sense that it can produce code that looks like a trading bot. It's false in the sense that you'd want to deploy that code on meaningful capital. The gap between those two statements is where all the work lives.

If you have the time, skill, and trading experience to do it yourself, that's a completely valid path. Most people asking "why would I pay for this?" don't have all three. Some have two. Many have one. The honest evaluation is: do you have everything you need to cross the gap between "bot that runs" and "bot that makes money in live markets over years"?

If yes: build it yourself. Seriously. I learned more about trading from writing my own bot than from any platform I ever paid for.

If no: you're paying for the gap.

The honest summary

Trading bots in 2026 are split into two categories: hobby-grade scripts that work until they don't, and production-grade systems that have been through enough live trading to catch the failures no tutorial covers.

GPT can help you build the first category in a day. The second category takes years, and most of that time is spent on things that don't show up in tutorials because they're not interesting to write tutorials about. The people doing the work are usually traders who had to become engineers, or engineers who had to become traders. Very rarely both from the start.

I'm still building unCoded the hard way because I'm the kind of trader who became an engineer because he needed to. The code reflects trading lessons. The architecture reflects engineering lessons. The pricing reflects the conclusion that subscription structures don't align with user outcomes. None of this is writable in a prompt because none of it is available to someone who hasn't lived it.

Vibe-coding is a legitimate way to learn. It's not a legitimate way to deploy meaningful capital.

Build your own if you have the patience. Pay for something built properly if you don't. The wrong answer is deploying a bot you don't understand on money you can't afford to lose.

The easy tools take your money. The hard tools either teach you to keep your own or earn alongside you when you do.

Pick accordingly.

Felix is the founder of unCoded — a self-hosted, non-custodial crypto Spot trading bot with profit-sharing pricing. Documentation at uncoded.ch/docs. ArrowTrade AG, Switzerland.