Signal

Don''t Freeze the Decision — Melt the Screen Layer, Freeze the Capability Layer

By makemind · Feb 6, 2026

February has opened. This month's main thread converges on a single line — don't freeze your decisions. All month long, we'll tap on this one sentence from many angles.

A quick read of the week's ecosystem
A quick read of the week's ecosystem

This Week's Signal

"Why We Left Compilation Behind" opened the door. The definition posed by this month's first Horizon piece set the theme for the week — compilation, in the end, is freezing a decision into a single hard block. The moment you press the build button, this screen hardens into this button, this color, this layout. To change it, there's no choice but to melt it down and bake it again. The piece's proposal is simple. Let's separate what to freeze from what to melt — melt the screen layer; freeze the capability layer. Capability (what the device can do) should be hard, but there's no reason to harden the screen (how you show it) along with it.

A screen on a chip followed as proof. Build's "On the Chip" arrived the same week and put the vision into our hands. An MCU evaluation board without a single line of dedicated GUI gets a screen from a single definition. When the vision says "don't bake," this piece shows "it runs unbaked" as a physical thing. With provocation and proof overlapping in the same week, weight settles in from the very first week.

The field piece began with a person. This month's Field opens with a farmer's notebook. A signal that we start not from abstraction but from a greenhouse in Hwacheon, Gangwon. From the first week, it lays down plainly that "making tools" is not a developers-only verb. When vision and proof come down from above, the field pushes the same sentence up from below — making happens not only at a desk but also in a field.

Tool & Package Notes

This week's note is about the boundary between what's frozen and what's melted. The capability layer — the part that reads sensors, writes values, and sends commands — is defined hard once and left as is. The screen that sits on top of it is handled as a definition. When you want to change the screen, you don't rebuild. Just fix the definition, and a different screen rises on the same capability. Where the cost of baking disappears, the freedom to keep tweaking moves in. On an evaluation board or in a greenhouse, the rule is the same — bake only what must be hard, and leave what changes often as a definition.

A Brief Thought

Saying "leave compilation behind" doesn't mean hating the compiler. Compilation is still needed to harden capability. What we leave behind is the habit — the habit of baking the screen in alongside it every time. The sense of choosing what to freeze and what to melt, that's the theme that will follow us all month.

From the Field

Jeong Bok-san (58) raises tomatoes in 8 greenhouse bays in Hwacheon, Gangwon. What he's decided to make this year isn't some grand system but a cultivation notebook — a tool to record, in a screen that fits his own hand, the temperature he checks every day and the time he waters. "Apps made by others have the wrong fields" was his starting point. Store-bought apps, he says, either had too many fields or were missing the one he actually needed. Fitting the fields to his own farm — that's the seed of the story this month will follow. The smallest proof of "handling the screen as a definition rather than baking it" might just be a farmer's three-field notebook.

This Week's Question · Next Week's Preview

In your work, what is the capability you must freeze and the screen you should leave melted? Try splitting the two onto paper. Next week, "Leaving Compilation Behind" goes one step deeper and asks "then where does the screen live?", and brings the scene of Jeong Bok-san drawing his first field by hand.


makemind.dev "Signal" — February, Week 1. Opening the door to a new month.

Twitter