Building Analytics First, Not Last: Why I'm Rethinking the Data Layer in My Side Projects

Last month, I spun up a small betting pool app with some friends for the cricket season. It took me three weeks to realize I'd built the worst possible analytics setup: events scattered across three different database tables, no audit trail, and when a payout calculation went sideways, I had no way to trace what happened. I spent a Friday night reconstructing bets from logs and application memory. That's when I stumbled on this World Cup companion app, and it forced me to reconsider how I approach data pipelines in projects I don't expect to scale.

The creator here did something I rarely see in side projects: they treated the analytics layer as a first-class citizen from day one, not an afterthought. And they did it honestly—admitting what wasn't deployed, showing what was proven locally, and explaining why each decision mattered. That kind of transparency is exactly what I needed to see when rethinking my own approach.

The Parimutuel Bet: Simple Math, Complex Trust

Let's talk about the betting mechanism first because it reveals something important about on-chain design. A parimutuel pool is elegant: everyone backs an outcome, all money goes into one pool, and winners split what losers put in. No house edge, no odds oracle needed. On paper, it's the perfect crypto use case.

But here's what struck me—they didn't just implement it, they specified it completely before shipping. There's a full written spec for the Solana program with worked examples and precise fee math. The payout calculation runs identically in Python and Rust, so the UI can show you exact numbers before you bet.

This is the opposite of how I usually work. I prototype fast, deploy, and fix edge cases in production. That approach kills you when money moves through your code.

The Real Insight: Analytics as Architecture, Not Reporting

The most interesting part isn't the betting—it's how they structured the data pipeline. Every state change writes to an append-only event log in the same transaction as the actual update. Money amounts are stored as integers (USDC base units). Every event has a schema version and a dedupe key. The whole thing was proven locally in DuckDB before touching a real warehouse.

This is the opposite of what I see in most startups, where analytics is bolted on after the fact. A data engineer shows up month six, finds a mess of inconsistent events, and spends three months reverse-engineering business logic from application code.

My Take: Honesty Over Polish

What I respect most is the honesty. The Solana program isn't deployed to devnet—they explained why and showed you the spec instead. The Snowflake integration is a proven local design, not faked with screenshots. This matters because it's the difference between a resume-padding demo and something you can actually learn from.

I'm guilty of the opposite. I've shipped GIFs of features that barely work, skipped the hard parts, and moved on. This project makes me want to be more rigorous about the parts that matter—especially anything involving money or state that can't be recovered.

Where I'd push back slightly: there's a risk in designing for a warehouse that might never exist. Every denormalization, every append-only log, every integer-instead-of-float decision adds friction to the current codebase. That's a trade-off worth making if you're actually going to scale, but for a side project, I'd want to see the inflection point where this design pays for itself.

A Practical Pattern Worth Stealing

Here's the payout math they include as a test case:

# Winning pool includes this bet; fee is charged on profit only
winning_pool = 200  # USDC base units
losing_pool = 800
stake = 100
fee_bps = 200  # Premium tier: 2%

profit = stake * losing_pool // winning_pool  # 100 * 800 / 200 = 400
fee = profit * fee_bps // 10_000  # 400 * 200 / 10000 = 8
payout = stake + profit - fee  # 100 + 400 - 8 = 492

The fact that this exact example ships as a test case, mirrors the Solana program, and gets validated before any deployment—that's the pattern I'm stealing. Money math should be tested to the base unit, always.

What's Next

I'm going to revisit the betting pool I built and add an event log with proper schema versioning. Even if it never hits a real data warehouse, the discipline of thinking about append-only events and exact precision will make the code more reliable and auditable.

The question for you: what part of your side projects would change if you designed the analytics first?

Source: This post was inspired by "For the love of the game: a World Cup companion with on-chain betting and Snowflake-ready analytics" by Dev.to. Read the original article