This piece has an evidence version. The same subject was made again, with running code and screens that were actually rendered — Sitting Down Without an Interpreter — Where One Piece of Judgment Becomes a Rule. This one is left as it was written.
"You can make your own tool, too." This magazine says it again and again. And yet the phrase has a corner that gives people pause. It sounds like start from bare ground. The picture of sitting before a blank screen and building something out of nothing. The blankness of an empty canvas weighs on anyone. Most people turn back right there with a single line: "But I don't know how to develop." And that turning back feels reasonable — making a tool is a specialized skill, after all. So the more qualified someone is to build, the sooner they turn away.
This volume corrects that picture head-on. The truth is the opposite — the people who'd most benefit from making a tool already hold the hardest part. It is not bare ground. It is the work of laying a final layer on a place where eight-tenths is already built. This piece traces what that eight-tenths is, why the missing two-tenths was such a vast wall, and how that wall came down.
Where the difficulty of a tool lies
First we have to ask. In making a tool, what is genuinely hard? People often answer "coding" — the skill of drawing the screen and wiring up the behavior. But look closely, and the real difficulty of a tool isn't there. It lies in knowing what to put in it.
Consider. Nearly every digital tool in the world could already be built, technically. The skills for drawing screens and handling data have matured enough. And yet countless tools go unmade. Why? Because the person who knows what should go into the tool and the person who can build it are different people. And knowing what should go in is far harder than the skill of building.
Take an example. Say you're turning a lawyer's consultation flow into a screen. The hard part isn't drawing buttons. It's knowing in what order to ask what, which answers split the flow, what omission puts the client at a disadvantage, which questions must not be asked first. Only after "lease or sale?" is settled do the next seven branches mean anything; "did you bring the original contract?" must be asked first, not third; leave out one line on the statute of limitations and the client loses a right entirely — none of this is in any coding book. It lives only in the lawyer's head, inside thousands of consultations. Anyone can learn the skill of drawing a screen, but the judgment of what to draw belongs only to those who have lived that domain.
This is the heart of it. Eight-tenths of a tool is judgment. What matters and what's incidental, in what shape data must be held to be of use, which exceptions must be handled — that judgment, the domain expert already holds. It isn't something to be learned anew with difficulty; it's already in hand from long doing. And that judgment is brutally hard to transfer to another. Try to explain it, and you run aground before the countless branches of "well, it depends." That entire map of "it depends" — that is the tool.
Put another way, in making a tool the code is a thin layer laid on last, and the thick layer beneath it is all domain knowledge. For a long time we had this ratio backwards. We took the most visible thing — screen, code, buttons — to be the body of the tool. So "make a tool" got translated into "do coding." But take a well-made tool apart, and the code is merely the vessel that carries the judgment held within it. Vessels can be bought anywhere. What goes inside — the thirty years of the person who made it — is the truly scarce thing.
Eight-tenths of a tool is not code but judgment. And that judgment is already in the hands of the very person who'd most benefit from building.
The hard part is already finished — in many places
Look again at this magazine's past pieces, and they were all the same story.
The LCD panel company. For thirty years they have made good panels. Bright, color-accurate, long-lasting. Evening out the backlight, tuning the color temperature to 6500K, guaranteeing tens of thousands of hours of life — the deep know-how of driving a display. That is the hard foundation. They couldn't make an HMI not because they lacked that foundation, but because the one axis of handling what goes on the screen was missing. They knew how to make the world's best panel, but the control screen to put on that panel was always someone else's job. Holding eight-tenths (the panel), they stopped before the two-tenths (the screen) and handed it off to an outside shop. And the screen the shop drew never passed through the hands of the people who knew the panel's character best.
The farmer. Thirty years of growing knowledge — which crop to move when, what a certain spring morning's air means, which signs foretell a poor harvest. That is the hard foundation. What was missing was only the one screen axis to hold that knowledge. Thirty years of records lived in a faded notebook and in his head, and for want of one layer to carry them onto a screen, they never became a tool.
The accountant knows the rules of reconciliation. Which item goes where, what the common mistakes are, where to look when a number doesn't match. The floor lead knows the quirks of the machines. When this machine makes a certain sound near the bearing, it's a sign it'll stop within three days; which faults come often in the rainy season; which valve must be turned one notch past the manual's number or it leaks. The teacher knows the standards of grading. What earns full marks and what loses points, and which trap in question three students slip on the same way every year.
What these people hold — the judgment of deep domain knowing — is something no outside developer can hold in their place. Try to carry it across through explanation, and the subtlety wears thin along the way. The nuance of "well, this case is a little different" disappears as it passes through a requirements document and a developer's interpretation. What the floor lead called "this sound" becomes "in the event of abnormal noise" in the document, and thirty years of ear evaporate whole in the gap. So having the one who knows best build it directly is the only way not to lose the eight-tenths. And that eight-tenths — with nothing new to learn — is already there.
Why the missing two-tenths was vast
So what was the missing two-tenths — the one axis of the screen? And why was it a vast wall that stopped people who held eight-tenths?
It used to be that making a single screen came with a long line trailing behind it. Set up a development environment, learn a programming language, write the screen in that language, handle the build tools, install it onto the device, and run that whole loop again from the start every time you change something. (In a past volume we called this line "the chain of thawing the ice and freezing it again.") Not one box in this line was familiar territory to someone who had spent a life arguing cases or working a field. Most got stuck at the very first box — setting up the development environment. To put a single button on a screen, you had to pass some ten gates that had nothing to do with the domain.
So for a domain expert, this two-tenths was not two-tenths. Small in volume, it was in height an effectively impassable gate. Someone holding eight-tenths in hand stopped before the wall of the final two. "This, I know best — and I can't make it" was the one sentence of that stopping.
Picture this once. A thick tower of foundation is already stacked to eight-tenths height. Lay just one final layer — the screen — on top, and it becomes a tool. But before that final layer stood a wall: thin in volume, yet sheer and vertical. Two-tenths by measure, and that two-tenths — for there was no way up — rendered the whole eight-tenths useless. The stopping wasn't for lack of the eight-tenths. It was for lack of a ladder to reach the final layer.
So for a long time the order ran like this. The person who knew the domain explained from behind, and a developer who could clear that two-tenths built from the front. The eight-tenths and the two-tenths were split between different hands, and the subtlety leaked out in between. Meetings were scheduled, requirements became documents, quotes came back, schedules slipped, and when the first draft arrived it sent you back to "no, in this case…" — that round trip itself shaved the eight-tenths bit by bit. And many small tools — too trivial to call in a developer — were never made at all. Before the threshold of "do I really bother a developer with something this minor?", countless needs were simply endured. Inconveniences propped up with a single spreadsheet, patched on paper, hardened into "that's just how it's done." The sum of those inconveniences was larger than anyone ever counted.
When the height of the two-tenths comes down
What the server-definition approach changed is exactly the height of that two-tenths. Instead of writing the screen in code and burning it onto a device, you hold the screen as a definition. What you have to learn is not a vast new system but one thing: "how to write a definition" — setting down, in an agreed shape, what to show where, and what each button does. No build, no burning cycle, no deployment chain is there. A first screen can begin in ten lines (this magazine's coding pieces open those ten lines).
And so that axis becomes something you lay on — not build from scratch. Onto the thick foundation you already hold, you set one screen layer that uses it. The weight of the word "make" shifts from build to complete. The person holding eight-tenths can lay the remaining two-tenths themselves. The domain expert moves from the seat where they explained from behind to the seat where they make from the front. The subtlety that used to wear thin through explanation becomes a screen without wearing at all. The floor lead's intuition of "this sound" becomes an alarm rule directly, with no interpreter.
The same work — one person spends three days explaining it to another; another lays it on themselves in an hour. The difference isn't talent. It's whether a ladder was set between.
Of course the two-tenths didn't become zero. Learning how to write a definition takes effort too. The first few hours are awkward, and there's trial and error before the agreed shapes feel familiar. But it is now a passable threshold — not an impassable gate. A first screen comes up in half a day, and in a few days you have something usable in your own work. That difference changes everything. An impassable 1m wall and a hand-span lip you step over with one foot — both are "obstacles," but one blocks the path and the other is simply crossed.
So who is the builder — the reinstatement of the soft
What this view overturns is "who can make." Not the person who learned to develop, but the person who holds the foundation of their domain. And here lies a reversal that is no small thing — the thicker the foundation, the longer the career, the deeper the domain, the stronger the builder, in fact. The missing axis is the same thickness for everyone, but the foundation held is that person's alone. Even when both learn the same way to write a definition, the consultation tool a thirty-year lawyer makes and the one made by someone who began practicing yesterday differ by eight-tenths. The length of the ladder is the same for all; the height of the tower the ladder reaches differs from person to person.
This is also a reinstatement of what was long regarded as "the soft." In the age of technology, domain experience was always treated as secondary, dismissed with "that's not technical," handled as an input to be explained and handed off to a developer. A lawyer's intuition, a farmer's feel, a floor lead's sharp eye — these were classified as "soft things, hard to turn into data," and seated at the back. The person who had worked longest in the room sat farthest from the seat where things were actually made. Now that thick experience stands at the front. The one who has done it longest makes it best. The depth of one's own field — long thought to be "nothing much" — becomes, in this structure, the core asset of the tool.
The one who has done the work longest makes it best. Depth is no longer an input you explain and hand off; it becomes the tool directly.
Honestly
Of course not every two-tenths came down equally. Work that's hard to express as a screen — precise real-time processing, complex algorithms, deep system integration, handling large numbers of concurrent users — still needs a developer's hand. Control that races against the millisecond, a backend taking hundreds of thousands at once, the bedrock of finance where not a hair may be off. One thing, "how to write a definition," does not make everything possible. Large products and intricate services are still the domain of professional development, and will remain so. This piece doesn't deny that seat — it only says the era is over when that seat acted as if it were everything.
And holding eight-tenths is no guarantee of making the screen well. Knowing what to put in, and arranging it to look good and work well, are work of a different grain. The first tool a domain expert makes may be rough. The buttons may be off, the colors dowdy, the flow tangled in a place or two. But that rough tool — because the eight-tenths of judgment is alive in it — is often more useful than a slick outside tool that missed the core. Roughness can be smoothed, but a missing eight-tenths can't be filled by smoothing.
What this era opens is the place of the countless small tools that lived in between. Between large products and outside shops — the things people holding eight-tenths gave up on before the two-tenths wall. Tools that fit your work exactly, that only you use, that you tweak often. Things too small to sell to anyone and too modest to call in a developer, that we simply lived without. And the sum of such small things is by no means small. Most of the world's work runs on top of those "small things."
Next
So in this volume we visit the places where the foundation was thick but the one screen axis was missing. The instrument on the lab bench, waiting to be handled without dedicated software. The teacher who held all the standards of grading in her head but had no screen to hold them. We watch them lay on that missing axis themselves. What happens atop the tower of eight-tenths, once a ladder is set.
You have a foundation like that too. Something you've done so long you know it with your eyes closed. An area where you think, "this, I know best." The thing you've long seated at the back yourself, saying "that's just what I do, it's no kind of skill." That is the eight-tenths. It is not bare ground. What's missing is just one axis — and that axis is now something you lay on.
makemind.dev "Horizon" — We watch the places where one screen axis is laid onto a thick foundation, at an instrument and in a classroom.