The Field Before the Product
JEFIELD means 제 필드, my field. A note on why the hardest engineering problem so far has been resisting the gravity of what everyone assumes the product is.
Date
Category
Writer
There is a word in Korean, 필드, borrowed straight from English, that has drifted slightly in the borrowing. In English a field is agricultural or academic or magnetic. In Korean it carries something closer to the ground you work. A place with an edge to it. Somewhere that is yours not because you bought it but because you are standing on it.
JEFIELD is a contraction of 제 필드: my field. I have been building it for most of a year, and for most of that year the hardest problem has not been storage, or synchronisation, or rendering. It has been holding the product still against the gravity of what everyone assumes it is.
Fig. 1. Damyang, Korea. Photograph by yong chern lee, CC BY 2.0, via Wikimedia Commons.
Naming is a constraint you agree to live under
A name does two things. It tells people what to expect, and it tells you what you are not allowed to build. The second job is the useful one, and almost nobody uses it.
When I say the word field, I have committed to a set of properties that are now expensive to violate. A field has an edge. A field is somewhere rather than something. A field does not curate itself. A field accumulates what you put in it, in the order you put it there, and it does not reorganise overnight. If a feature request would make JEFIELD stop behaving like a field, the name is already an argument against it, and I did not have to invent that argument in the moment.
Compare this to the names the product was in danger of receiving. Second brain commits you to synthesis, to connection-making, to a system that thinks. Vault commits you to security and to a door. Workspace commits you to collaboration and to tasks. Each of those is a fine product. None of them is this one.
What it is not, written down and kept
I keep an explicit list. It looks defensive and it is. A product drifts toward its easiest description the moment you stop holding it in place, and every item here was at some point a sincere suggestion from a reasonable person.
The assumption | Why it is wrong | What it would cost |
|---|---|---|
It is an AI | AI is a capability used inside it, never the thing itself | The product dies when the model is unavailable or repriced |
It is a chatbot | There is no conversation partner. The field does not answer | An expectation of dialogue that the record cannot honour |
It is an AI pet | The cat is a face, not a relationship simulator | Manufactured emotion, which is the one thing forbidden |
It is a memory app | It does not extract, infer, profile or summarise | Becoming a weaker version of products that already do that well |
It is a Tamagotchi | Nothing needs feeding. Neglect has no penalty | Obligation, which turns a place into a chore |
It is a productivity app | There are no tasks, no completion, no streaks | A measurement layer that changes the behaviour it measures |
It is a set of apps | One world, reached through many surfaces | Device-shaped ownership, which is the wrong shape entirely |
Table 1. The seven descriptions the product is most often mistaken for, and the specific cost of accepting each.
The working definition
A user-owned temporal personal environment. A personal space where your time accumulates.
It is a clumsy sentence and I have not found a better one. Every word is carrying weight.
User-owned is an architectural claim before it is an ethical one. The ownership shape is USER to WORLD to DEVICES, never DEVICE to WORLD. A device is a window. If you throw a device away, nothing of yours was in it. This sounds obvious and almost nothing is built this way, because building it the other way is easier and the difference only becomes visible on the day someone loses a phone.
Temporal means a year in it has to differ from a day in it. Not cosmetically. Structurally. If the interface looks identical after twelve months of accumulation, the time never entered the product, and you built a folder with a nice font.
Personal means nothing arrives that you did not put there. No feed, no recommendations, no suggested items, no discovery. This is a severe constraint that removes most of the growth mechanisms available to software, and it is the reason the field has the one property nothing bundled has: everything in it was placed deliberately.
Environment means you enter it. You do not query it.
The cat, and why it has exactly one job
There is a pixel cat in JEFIELD. People see the cat first and conclude, reasonably, that the cat is the product. It is not. The field, meaning space plus time plus state plus memory plus relationship, is the product. The cat is its face.
Which gives the cat a single, strange assignment: show that the world was remembered, not that the software is clever.
A cat that performs is decoration. A cat that is simply present, and is present differently after a three-week absence than after three minutes, is evidence. The distinction sounds small in a sentence and it governs every animation decision in the product.
AI is a capability, never the owner
This is the rule I expect to be argued with hardest, so let me state it in its testable form rather than its inspirational one.
AI inside JEFIELD is a replaceable component, in the same category as a font renderer or a compression library. It may read a file and report what it found. It may not own the record, may not be the product, and may not be the reason the thing has value.
The test is mechanical:
That test has killed more feature ideas than any roadmap meeting. It is also the reason I expect the product to be worth more as AI improves rather than less: if the field holds your material in a form you own, then every better model that arrives is a better lens on a corpus that was already yours. If the model holds the material, every model change is a migration.
Why a design studio is building software at all
The honest answer is that I noticed an asymmetry and could not stop noticing it.
Every tool I use to hold my own work is designed with enormous care around the moment of saving. The gesture is fast, the feedback is immediate, the friction has been sanded down over a decade of iteration. And almost none of them are designed around the moment of coming back. That half is left to search, which requires you to already know what you are looking for, and to folders, which require you to have predicted the future at the moment you were least equipped to.
The saving half is solved and free. The returning half is unsolved and expensive. And the reason the imbalance persists is not neglect. It is that saving is deliciously easy to build and to demonstrate, and returning is neither.
What this journal is going to be
This is the first of what I expect will be a long run of notes about building it. I want to set an expectation, mostly for myself.
I am going to write the corrections as carefully as the discoveries. There are already several. A study I cited turned out to measure something other than what I claimed. A conclusion I defended for a month was invalid because of a missing configuration file. An aesthetic direction I had publicly committed to was discarded. In my experience the corrections are the only part of a build log that is worth reading later, because they are the only part that contains information the writer did not already have when they started.
The alternative is the genre where everything was difficult and then everything worked, which is retrospectively coherent and teaches nothing.
Sources
Damyang, Korea. Photograph by yong chern lee, CC BY 2.0, via Wikimedia Commons. commons.wikimedia.org/wiki/File:Korea-Damyang-Rice_paddy_field-01.jpg
Bush, V. (1945). As We May Think. The Atlantic, July 1945. Full text: web.mit.edu/sts.035/www/PDFs/think.pdf
Related reading
Latest Articles.
© Moc Mallen Studio
Thoughts, ideas, and perspectives on design, simplicity, and creative process.
