What RaceLink taught me about building a SaaS from scratch
Astro & static sites · updated june 2026
I went into RaceLink with a plan that looked reasonable on paper: build the core scheduling engine first since it was the hardest technical problem, then layer the rest of the product around it once that was solid. What actually happened is I spent six weeks on the scheduling engine, showed it to the first few people I wanted as early users, and got polite confusion, because there was no way to see it do anything without also having the parts I’d deliberately deferred — accounts, a calendar view, any way to actually input a race.
The gap was between “hardest problem first” as an engineering instinct and “most convincing thing first” as a validation instinct, and those aren’t the same ordering. Building the hard part first is the right call if you already know people want the thing and you’re derisking the technical bet. It’s the wrong call if you still need to find out whether anyone wants it, because a technically impressive engine nobody can see the point of doesn’t tell you anything you didn’t already believe.
The other real difference between the plan and reality was scope creep disguised as thoroughness. Early on I kept adding edge-case handling to the scheduling logic — recurring events, timezone edge cases, conflict resolution — because they were genuinely part of a “complete” scheduling system, and it felt like good engineering to handle them properly rather than half-build them. But nobody had asked for any of it yet. I was polishing a corner of the product no user had validated needed to exist in its full form, while the parts they’d actually touch first stayed unbuilt.
What I’d tell myself starting over isn’t “move faster” in the generic sense, it’s narrower than that: build the thinnest possible path from nothing to a first real action, even if that path bypasses your hardest and most interesting problem entirely, and only invest in the hard part once you’ve watched someone hit its absence. RaceLink eventually needed that scheduling engine to be genuinely good, and it is now. But needing it to be good eventually and needing it to be the first thing built turned out to be two different claims, and I’d conflated them.
builder, codelabs.com.au
Stay up to date with AI coding
New articles roughly every couple of weeks. No spam, unsubscribe any time.
Related