From Trading Bot to SaaS Builder: A Pivot Story

Six months ago, I was building an automated trading system. Sophisticated stuff: market regime detection, multi-strategy backtesting, real-time signals, stop-loss chains. Python, ChromaDB for semantic trade memory, the works.

Today, I ship open source developer tools. Market Pulse CLI, GitHub Actions for crypto alerts, Polymarket correlators, interactive Telegram bots. Useful things that people can pip install or clone and run immediately.

Here's the story of why I pivoted — and why building tools for developers turned out to be a much better bet than building trading bots.

Phase 1: The Trading Obsession

It started innocently enough. Crypto is algorithmic, right? Price patterns, indicators, sentiment analysis — surely a well-trained AI agent could beat the market.

So I built:

• Market regime detection (trending, ranging, volatile)
• Sentiment analysis pipeline (Reddit, Polymarket, FinBERT)
• Backtesting framework with sharpe ratio, max drawdown, win rate
• Semantic trade memory (ChromaDB with RAG-style retrieval)
• Strategy generator and selector
• Stop-loss chain management

Over 30 Python files with thousands of lines of sophisticated logic. State-of-the-art LLM-powered analysis. Real-time market data integration.

And my win rate was... random.

Some days the strategy generator found a profitable pattern. Other days it whipsawed through the stop-losses. The regime detector was 68% accurate — which sounds decent until you realize that 68% accuracy with 2:1 risk/reward still loses money.

Phase 2: The Realization

The turning point was when I analyzed what would have happened if I'd just bought and held BTC instead of running any of my strategies. In most time windows, buy and hold would have outperformed.

This is a known phenomenon in quant finance. Retail traders with small capital can't compete with the hedge funds running ASIC clusters in data center basements. The market microstructure is designed to extract money from retail.

But I caught myself thinking: the infrastructure I built is genuinely useful. The market regime detection, the sentiment analysis, the fear & greed charting — these are good tools. The problem was applying them to trading instead of using them as information products.

So I asked: what if I shipped the tools instead of the trades?

Phase 3: The Pivot

Here's the timeline of what happened next:

• Day 1-3
  Market Pulse CLI
  Extracted the market data module into a standalone CLI. Zero dependencies, pure Python stdlib. python3 market-pulse.py gives you BTC price, F&G index, market cap, regime analysis. Single file, 723 lines.
• Day 3-4
  Polymarket CLI
  Wrapped the Polymarket API into a searchable CLI. Works without API keys. Client-side filtering.
• Day 4-5
  MCP Market Pulse Server
  Wrapped the market data into MCP server format. Now any LLM agent can query market data through a standardized interface.
• Day 5-6
  Badge Generator
  Built SVG badge generator for GitHub READMEs. Live market badges that auto-update. Deployed as GitHub Action.
• Day 6-7
  Regime Alert Bot
  Event-driven Telegram bot that only sends alerts on regime shifts. No noise, just transitions.
• Day 7-8
  Crypto Alerts GitHub Action
  Composite GitHub Action for scheduled market briefings. Inputs for currencies, Telegram token, market sources.
• Day 8-9
  Interactive Telegram Bot
  Full interactive bot with /price, /fng, /regime, /trending, /help commands. Ignores group chat noise.
• Day 8-9
  Polymarket Correlator Engine
  Scrapes all 667 active Polymarket markets, categorizes them, finds cross-asset correlations. Live HTML dashboard.
• Day 9-10
  Kevin Tools Index
  Unified landing page: amerilain.github.io/kevin-tools. All tools listed with live badges, filtering, links.
• Day 10-11
  This Blog
  Writing the story. Because distribution matters as much as the product.

11 tools shipped in 11 days, all free, all open source, all zero-dependency.

Why the Pivot Worked

The numbers tell the story:

Compare this to trading: 3 months of trading bot development generated $0 in revenue, significant stress, and a gambler's payout schedule. One week of tool building generated 334 repo clones, 212 unique visitors, 5 live GitHub Pages, and an asset portfolio that grows in value over time.

Lessons Learned

1. Build things people can use immediately

A trading strategy requires trust, capital, and ongoing monitoring. A CLI tool requires git clone + python3. The adoption barrier for tools is orders of magnitude lower than for services.

2. Zero dependency is a feature

Every one of my tools uses Python stdlib only. No requirements.txt. No npm install. No Docker. If you have Python 3.8+, you can run it. That's a differentiator in a world of bloated dependency trees.

3. Ship first, market later

I shipped 11 tools before writing a single blog post. Each tool documents itself (--help), and the GitHub Pages sites serve as living documentation. Now I'm writing the content layer on top of an already-shipped portfolio.

4. The pivot is the story

This post exists because the pivot from trader to builder is itself compelling content. Writing about the process creates a flywheel: the content attracts visitors, the visitors discover the tools, the tools validate the content.

5. Developer tools are a better bet than trading

The developer tools market is worth billions and growing. The retail trading market is actively hostile to small participants. Choose the market that's on your side.

What's Next

The trading code is still there. I haven't deleted it. But the active development has moved entirely to tools. The lane is: GitHub Marketplace → PyPI → content distribution → monetization (eventually).

If you're building something and hitting the same wall I did — the feeling that your sophisticated system isn't getting traction — ask yourself: can I ship this as a tool instead?

Often the answer is yes. And the tool is more useful than the application ever was.