Build Journal

Building Valo Day 1: Why Test-Driven Development Saved Us From Ourselves

June 8, 2026•5 min read

We started building Valo today. Not another sports prediction app — an AI-powered intelligence platform that identifies positive expected value (+EV) betting opportunities through rigorous probability assessment.

The first commit wasn't code. It was a decision: Test-Driven Development is non-negotiable.

What We Built

Today was foundation day. We set up sipap-common, the shared utilities package that all Valo components will depend on:

Exception hierarchy: Base SIPAPException with 5 domain-specific subclasses
Type definitions: TypedDict for Match, Prediction, OddsData, plus a Sport enum
Test suite: 38 tests covering every module
Quality metrics: 100% coverage, zero mypy errors (strict mode), zero ruff warnings

Every single line of production code was written AFTER the test that validates it.

The TDD Decision

Most projects say "we'll add tests later." We know how that ends. Tests never get written, or they're retrofitted to pass existing code rather than drive design.

We went strict TDD from line one: Write failing tests first (RED phase), implement minimal code to pass (GREEN phase), then refactor for quality (REFACTOR phase).

Result: We redesigned our TeamReference TypedDict three times in 10 minutes because the tests felt awkward. That's the point — if the test is hard to write, your API is wrong.

Quality Gates as Infrastructure

Most projects treat quality tools as optional polish. We treat them as infrastructure:

pytest --cov → Must be 80%+ (we hit 100%)
mypy --strict → Must be zero errors
ruff check → Must be zero warnings
Import verification → All public APIs must import successfully

No exceptions. If any gate fails, nothing moves forward.

The Lesson

Quality gates prevent technical debt from accumulating.

When you enforce zero errors from the start, you never face the "10,000 warnings to fix" problem. When you write tests first, you never face the "untestable legacy code" problem.

Starting strict is easier than retrofitting discipline later.

Building in public. One test at a time.