From Side Project to Automated Trading: Building TrendRider

Every developer has that moment when a side project stops being a weekend experiment and starts demanding real architecture decisions. For me, that moment came when my Freqtrade bot made its first profitable trade on Bybit -- and I realized I had no idea if it was actually good or just lucky.

This is the story of building TrendRider, from a single Python script to a full platform with a landing page, performance dashboard, and automated signal delivery.

The Problem

I started trading crypto manually in 2024. The results were predictable: emotional decisions, missed exits, and the constant stress of watching charts. So I did what any developer would do -- I wrote a bot.

Freqtrade was the obvious choice. Open source, Python-based, solid community. Within a week I had a strategy running in dry-run mode on Bybit. It was making paper trades, and they looked... promising?

But here's the thing about trading bots: you can't tell if they're working by watching individual trades. You need aggregate statistics. Win rate, drawdown, profit factor, Sharpe ratio, performance across market conditions. One winning trade means nothing. A thousand trades with consistent edge means everything.

I needed a dashboard. And that side project was born.

The Stack

The bot itself runs on a VPS:

• Freqtrade for strategy execution
• Bybit as the exchange (good API, reasonable fees)
• SQLite for trade logging
• Telegram for real-time alerts

The landing page and dashboard are a separate Next.js application:

• Next.js 16 with static export
• Tailwind CSS for styling
• Vercel-style deployment on a VPS with nginx

The two systems communicate through Freqtrade's REST API and a custom data pipeline that aggregates trade history into dashboard metrics.

The Hard Parts

1. Backtesting vs. Reality

My first strategy had a 78% win rate in backtests. In dry-run it dropped to 52%. The gap came from three things I hadn't accounted for:

• Order fill timing -- backtests assume instant fills, reality doesn't
• API rate limits -- Bybit throttles requests, causing delayed entries
• Market microstructure -- the spread on smaller timeframes ate into profits

The fix wasn't more indicators. It was simpler logic with wider margins. The final strategy uses three indicators (RSI, EMA crossover, MACD) and performs at 67.9% win rate with 1.42% max drawdown. Less clever, more robust.

2. The Dashboard Problem

Building a performance dashboard for trading is harder than it sounds. The naive approach -- show a P&L chart -- hides critical information. A 10% monthly return means nothing if the max drawdown was 15%.

I ended up building an investment simulator that lets visitors plug in their own capital amount and see projected returns based on actual historical performance. No cherry-picked trades, no hypothetical scenarios. Just the real numbers, extrapolated.

The key insight: transparency builds trust faster than marketing. When people can see every trade, every loss, every drawdown, they either trust the system or they don't. No hard sell needed.

3. Going from "It Works on My Machine" to Production

The bot running locally is one thing. The bot running 24/7 without supervision is another. Things I learned the hard way:

• systemd is your friend. Auto-restart on crash, log rotation, resource limits.
• Health monitoring is not optional. A bot that silently stops trading at 3am is worse than no bot. I built a health checker that pings Telegram if the bot misses an expected heartbeat.
• Configuration management matters. When you're tweaking parameters on a live system, one typo can cost real money. Version-controlled configs with validation before deploy.

# Health check that runs every 5 minutes
*/5 * * * * curl -sf http://localhost:8080/api/v1/ping || \
    telegram-notify "Bot health check FAILED"

What I Would Do Differently

Start with the dashboard, not the bot. The bot is the easy part (relatively). Understanding whether your bot is actually performing well -- that's the hard part. If I'd built the analytics first, I would have caught the backtesting gaps months earlier.

Deploy to production sooner. I spent weeks perfecting the strategy locally. The bugs I found in production (API timeouts, exchange maintenance windows, timezone issues) could only have been found in production.

Don't build everything yourself. I initially wrote my own backtesting engine. Three weeks of work that Freqtrade already does better. Use existing tools for the commodity parts and focus your energy on what makes your project unique.

Where It Is Now

TrendRider runs 24/7 on a VPS, trading 5 pairs on Bybit. The landing page at trendrider.net shows live performance data, and an investment simulator lets visitors see projected returns with their own capital amount.

The next phase is proving the strategy works under professional scrutiny -- prop trading evaluations where you trade with the firm's capital. That's the real test: can the bot perform when someone else is watching?

Advice for Developer Side Projects

1. Ship something small first. My first "release" was a Telegram bot that sent trade alerts. No dashboard, no landing page. Just alerts. That was enough to validate that people cared.

2. Track your metrics from day one. Not vanity metrics. Real ones. For a trading bot, that's win rate, drawdown, and profit factor. For a SaaS, it's activation rate and retention. Whatever your core metric is, instrument it early.

3. Transparency is a feature. In a space full of scams and fake screenshots, showing real numbers -- including the losses -- is a competitive advantage.

4. The boring infrastructure work is the most important work. CI/CD, monitoring, automated deploys, health checks. None of it is exciting. All of it is what separates a side project from a product.

---

You can see TrendRider's live performance dashboard at trendrider.net. The code runs on Freqtrade -- if you're interested in building your own, their documentation and Discord are excellent starting points.