The first week gave us the proposition, the second the proof. The third week is the how — when sculpting capability into tools, where do you actually draw the line between exposed and unexposed?
This Week's Signal
Where you draw the line is the app's character itself. With the same server, the same capability, it becomes an entirely different app depending on which tools you offer and which you close. The exposure list is a declaration of capability; the non-exposure is a declaration of character. That was the third week's core theme — "what to enable" is just as much design as "what to leave undoable." The two lists are two faces of one coin, and that boundary line tells you who the app is for.
The boundary is not a feature constraint but the foundation of trust. A closed-off tool is not a missing feature but a promise. Just as the black box promised "we don't touch the footage" through the absence of a tool, closure becomes a guarantee given to the person who uses it. An impressive line from the third week's reactions — "I trust it more because there are parts that are closed." A tool that can do anything is trusted less than a tool that clearly can never do certain things.
We've reached the center of Vol 4. The possibility that every server can become an app, and the responsibility of drawing a line across that possibility. This month speaks of both at once. The third week is that balance point — the sense of opening richly, but not opening dangerously.
Tool & Package Notes
This week's note is the order of boundary design. If you start from addition when designing tools, the list bloats and dangerous capabilities slip quietly in. The recommended order is the reverse — first make the list of "what this app must absolutely never do," and nail that down as the non-exposure zone. Then, within that line, you add tools. Decide what to close first, and opening becomes safe. Interestingly, following this order makes the tool list shorter. Because you've fixed the closed zone first, you end up keeping only the truly necessary capabilities. The boundary lends a hand to the design.
A Short Thought
The word "permission" is heavy. It sets in rules who can do what, checks, and denies. But moved into the unit of the tool, permission becomes a list. A tool that's there can be done; a tool that isn't can't. You don't have to read the rules — just look at the list and you know. Permission moved from code to spec — this is the quiet shift running all through April. And a spec can be read by people. Anyone, not just the maker, can open the tool list and know what the app promises and what it refuses. This is where trust becomes verifiable.
From the Field
Han Do-gyeong's process of sculpting the flow of care into tools followed this order too. He first drew "the line a tool must never cross" — the final judgment of diagnosis and prescription. After nailing that line down as non-exposed, he richly added tools for patient intake, organizing the consult, and tidying records within it. The pace of seeing 60 patients a day is aided by the tools; the weight of judgment is borne by the human. Because he decided what to close first, opening was free.
This Week's Question · Next Week's Preview
Have you ever written out the "closed list" of a screen you'll build? Usually we write only the features to open. This week's suggestion — write the closed list first. Next week we close out April with Han Do-gyeong's story in full — wrapping up how an experienced person's experience becomes a flow, and how a flow becomes a tool.
makemind.dev "Signal" — one breath each week, gathering a week's Signal.