The first thing worth building was a place for the other things. A document was not enough. A social feed was worse. The notes needed addresses, topics, and a way to point at each other. This page is the build note for that place. The messier reason for opening it lives in the journal. Here I want the decisions that a later reader, including me, can inspect without reconstructing the mood of the week I started.
The build is still in progress. That status is literal. The sections exist. The list does not. A few notes are long enough to stand on, and some shelves are still thin. Building, in this case, means the structure is real and the product is the structure. I am not waiting for a launch to call it a notebook. A launch would imply an audience I do not have and a completeness I do not want to fake.
A new essay is a new file, not a new tool. If adding a thought requires a project, the notebook has already lost.
Files, not a platform
Content lives in MDX files. Topics are folders. A new essay is a new file, not a new tool. There is no database and no CMS, on purpose. The structure should stay understandable by a person reading the repository. If I cannot explain where a note lives by pointing at a path, the system has become a product of its own, and the notes will start serving the system.
I have built the other kind. A CMS feels like progress because the interface is friendly and the schema looks like a plan. Then a small change needs a migration, a preview environment, and a conversation about roles. None of that writes the sentence. The sentence is the work. The file is the smallest container that still has a title, a date, and a body another note can link to. Git keeps the history. The history is the version control I actually use: what the claim used to be, and when it changed.
Folders are the taxonomy I am willing to maintain. Learn, experiments, notes from the job, builds, books, resources, journal. A note has one home. It can be cited from anywhere. I would rather have a slightly wrong folder and a working link than a tagging system so flexible that nothing has an address. Tags can ride along. They are not the map. The map is the URL, and the URL stays shallow so a person can say it.
This choice also keeps the site honest about what is unfinished. An empty folder is visible. A CMS with a hidden draft queue can look finished while the thinking is not. I want the opposite: the public page can be early, and the early page should not pretend to be a manual. What knowing marketing means is a standard for the writing. This build is the standard for the container. Both have to be simple enough to use on a tired evening.
What the structure has to hold
The notebook has to hold four kinds of object without turning them into the same kind of page. An essay argues. An experiment records a change and an outcome, including an outcome that is inconclusive. A note from the job captures a decision. A resource is a shape you can reuse: questions, a method, a template. If the template and the essay look identical in the file, they will look identical on the site, and a reader will not know whether they are being asked to agree or to copy a form.
So the front matter carries the difference. An experiment says whether it is running, documented, or inconclusive. A build says whether it is an idea or something already being made. A book says who wrote it and whether I have finished it. A resource says what kind of tool it is. The body can be long. The status cannot be implied by tone. Tone lies. A confident paragraph can describe a test that never had a measure. The status field is the correction.
| Object | What the file must say | What it must not pretend |
|---|---|---|
| Essay | A claim you can disagree with | That a category page is the claim |
| Experiment | Hypothesis, change, result, status | That a single try is a law |
| Job note | The decision, including the refusal | That a meeting happened, so learning did |
| Book note | The practice you kept | That the page is the book |
| Resource | A shape someone can reuse | That filling it in is the same as thinking |
| Build | Idea or in progress, plainly | That a sketch is a product |
What is still unfinished
The list is the unfinished part I care about naming. The form is on the page so the shape of the site is honest. It does not store addresses yet. I would rather show a closed list than pretend a list exists. A closed list is a small embarrassment every time someone types an email. The embarrassment is cheaper than a trust break. A site that writes about sequences of trust cannot open with a form that implies a relationship it does not have. The sentence on the form says the address was not saved. That sentence is part of the build, not a placeholder I forgot to replace.
Other unfinished pieces are ordinary. Some topics have one note when they deserve several. The cover is a shared mark, not a custom image per essay. Search looks across the notes that exist. None of that is a roadmap dressed up as a vision. It is a list of things that can wait because the file path already works. Waiting is a feature. A notebook that tries to finish its chrome before it has notes becomes a theme, and themes do not teach.
I also do not want a second product hiding inside the first. Analytics, accounts, comments, and a recommendation engine would each be a build with its own failure modes. They would also pull the writing toward whatever those systems reward. Comments reward reaction. Recommendations reward similarity. I want links I chose, because a chosen link is an argument. An automatic "related" row is a guess. Guesses can be useful later. They are not the spine.
What earns the next build
Later builds should come from notes that keep repeating. If a lesson shows up three times, it might deserve a template, a small tool, or a public framework. Until then, the build is the notebook. The rule of three is a brake. I like making things. Making things feels cleaner than revising a sentence. The brake says: show me the sentence in three places, with three dates, before the tool is allowed to exist.
The experiment log is the first idea sitting behind that brake. Experiments are already a section. A log would only be worth building if the notes stay in one shape long enough that comparison is the pain, not consistency. If I build the log while the notes are still sloppy, the log will freeze the sloppiness into fields. Fields are hard to abandon. A paragraph is easy to rewrite. So the prototype stays the section. The idea stays an idea. That is the build discipline I want the rest of the site to imitate.
Make marketing inspectable is the essay version of the same brake. A path a stranger can follow beats a dashboard only the team can read. This repository is that path for the learning itself. You can see the file. You can see the date. You can see the link. You cannot see a private draft that contradicts the public sentence, because I am trying not to keep one. Where a note is unsure, the note says so. Uncertainty in public is uglier than a polished CMS and more useful to future me.
How a page gets added
The practical loop is short. Write the claim in a file. Give it a date in the form the site already uses. Put it in the folder that matches the kind of object. Link it from the note that made it necessary. Read it on the page, not only in the editor, because the page is where the quote, the table, and the tip have to earn their place. If a section exists only to lengthen the file, cut it. Length is for the argument, not for the appearance of seriousness.
I check the link with a human mouth. If I cannot say the address in two beats, it is too deep. The site's public paths stay short for that reason. A clever nest looks organized in the repo and becomes a maze in the browser. The repo can be nested. The reader should not have to learn the nest. One section, one slug. The folder inside learn can be richer than the URL. The URL is the promise.
Then I stop. Shipping the file is the build step. Tweaking the layout because the new essay feels visually lonely is how a writing tool becomes a design project. The shared page already knows how to render a heading, a table, a quote, and a tip. Use those. Do not invent a component for a mood. Moods are not a design system. The design system is the small set of blocks that make every note feel like the same publication.
What this build refuses
It refuses to be a company site. There is no menu of services hiding under the essays. It refuses to be a course. The notes are not modules, and there is no certificate at the end. It refuses to invent a personal brand character. The author is the person doing the job, named when there is a reason to name them, not before. It refuses fake numbers: no counters for readers, no pretend subscribers, no "as seen in" row.
Those refusals are positioning applied to the build. Positioning is a refusal. A notebook that tries to be a course, an agency, and a community at once will sound like all three and hold none of them. I would rather a reader leave because it is only a notebook than stay because it might be a funnel. The leaving is information. The staying, if it happens, should be because a note was useful enough to cite.
How I will know it worked
I will know the build worked when a decision in June can point at a sentence from October without a search through chat logs. I will know it failed if I start keeping the real thinking in a private doc again, and the site becomes a cleaned excerpt. The private doc already failed once, by having no addresses. The cure is not a prettier excerpt. The cure is that the public file is the place the sentence first appears.
A second test: someone else, or a later version of me, can add a note without asking how the site works. If the answer is "make a file, follow the front matter of the neighbor, link it," the build is done enough. If the answer is a tour of configuration, I have built a platform and called it a notebook. I am trying not to do that. The status stays building until the habit is boring. Boring is the success condition. The ideas can be sharp. The container should be dull.