This morning I was done. This afternoon I knew better.

This morning my trading system's momentum calculation ran flawlessly for the first time. 552 stocks, all with a score, the top twenty looked logical. Energy, a few tech names, a Dutch construction company.

I leaned back. Done. On to the next factor.

This afternoon I understood I wasn't done. Not even halfway.

A cheesecake without a fridge

Imagine you bake a beautiful cheesecake. Looks great, tastes amazing, your wife even says something nice. But you don't have a fridge. So the next day you spend another four hours in the kitchen replicating that cheesecake. For one guest. Every time.

That's how my momentum calculation worked this morning. Somewhere on my laptop. Once per run. Nobody else could access it. No history. No "what did I have yesterday". No dashboard could show it without me firing up the script again.

A cheesecake without a fridge.

The real work

This afternoon I built the fridge. Or rather: the database version of one.

Three things had to happen. Expand a table so the scores actually fit. Write a function that writes the calculated scores into that table. And write a check that immediately after writing reads back whether it's actually there. Trust is nice, verifying is better, especially when there's real money coming.

It all sounds like formality. It wasn't.

Two nasty details

Detail 1. My table required every row to have a value for "composite score". That's the final weighted sum of all four of my factors. Problem: I have only one factor done. Momentum. The other three are still in progress.

Two options. Drop the table requirement temporarily. Or fill in a placeholder value that we replace later. Option two chosen. With a note in my records: this is temporary debt. Remove later, otherwise this detail will still be there a year from now and someone will spend hours figuring out why the composite equals momentum.

Detail 2. A common creature in data work: the missing value. Software languages have different ways to indicate "empty". Python calls it "NaN" when it comes to numbers. Postgres databases want "NULL". Going directly from one to the other doesn't happen automatically. Errors arise. Nothing gets written.

Writing a small translation function was the solution. Ten lines of code. Not complicated. But without those ten lines, nothing happens.

These are two details you don't see when you only test your calculation. They live in the transition between "it computes" and "it sits somewhere others can access it".

What I can do with this now

With momentum scores neatly in the database I can from here:

Run a backtest. Not "what would my system do today", but "what would my system have done six months ago, and what return would that have generated". For that you need history.

Build a dashboard that shows the daily top ten BUY signals. That dashboard needs to be able to fetch scores from somewhere. Not from a script on my Mac.

Compare: which stocks were in the top ten yesterday and out today? That's only possible if yesterday's score is also stored somewhere.

That's the difference between "a calculation I can repeat" and "a foundation the whole stack can build on".

Persistence is not an afterthought

This morning I thought: today I'll finish the momentum factor. I meant: the calculation works. This afternoon I knew better. There was a whole integration layer behind it. About a third of the work time went into it.

For those building from scratch to production, here's the lesson: a working calculation is not the same as a working system.

Don't build your system only until your code works. Build it until your data lives somewhere others can reach. Until there's a fridge.

Otherwise you bake the same cheesecake again, every day, and it stops being fun.