The Toolmaker's Discipline: Niche of One

In the opening scene of 2001: A Space Odyssey, an ape picks up a bone and realizes it can be used as a tool. In that moment, the gap opens. The apes who can use tools will dominate those who cannot.

We’re in that scene again. But the gap isn’t between tool-users and non-tool-users anymore. It’s between tool-makers and tool-dependents.

The Future Work Mythology described what’s dying: teams, documentation, estimation, meetings, the enterprise itself. The scaffolding built around human limitations is collapsing because AI removed the limitations.

This is the companion piece. Not what’s dying—what to build instead. Not theory—practice. The discipline of the toolmaker in the age of AI.

Part I: The Revelation

The Graveyard and the Toolbox

I recently looked through my ~/src directory, sorted by date. Six months of building with AI. Over a hundred projects. A graveyard of ambition.

Some projects had 40,000-word READMEs. Comprehensive documentation. Test suites. Thoughtful abstractions. Product aspirations radiating from every directory.

They’re all dead. Untouched for months.

Other projects had no README at all. Hacky code. Single-purpose scripts. Built in a lunchbreak, never intended for anyone else.

They’re all alive. Running right now. Globally installed. Part of my daily workflow.

The pattern was undeniable:

The tools built with product aspirations died. The tools built selfishly survived.

But “died” is the wrong word. Let me look again at those dead projects.

Fractal-map became beist-fractal-map. Beist-fractal-map is becoming loom. The BEIST language—an entire programming language I built—was itself the second iteration of an idea. BEIST became Koru. The “dead” projects aren’t dead. They’re composted. They decomposed into something better.

This is the hidden cost of release: released things aren’t allowed to die.

If I had released fractal-map, I’d still be maintaining fractal-map. I couldn’t let it die and become loom. I’d be trapped in the amber of my past understanding, supporting users who depend on the old version, unable to let go and build the better thing.

The graveyard isn’t a graveyard. It’s a compost heap. The death is generative. Every “failed” project taught me something that lives on in its successors. The understanding compounds even when the code doesn’t survive.

But only if you let things die. Only if there’s no second user holding you hostage to the past.

But look at that last row. 6digit studio HAD product aspirations. It’s extremely polished. It has features that would genuinely benefit from a user community—shared brain fragments, cross-pollination of context structures, network effects. It COULD be productized. It SHOULD be productized, by pure product logic.

I chose not to.

Not because it wouldn’t succeed. Because success would cost more than failure. The second user would arrive, and with them, the scaffolding. The support tickets. The backwards compatibility. The defensive coding. The death of velocity.

6digit studio escaped the trap not by avoiding polish, but by refusing release despite the polish.

This isn’t survivorship bias. It’s a causal relationship.

“Just Open Source It”

Someone will say: “If you don’t want to sell it, just open source it. Share the wealth. Let others benefit.”

I’ve done this. Here’s a partial list of packages I published to npm in a single month:

• zontax (schema language)
• zod-subset-parser
• monaco-zod-subset-mode
• monaco-json-liquidjs-mode
• monaco-json-jsonata-mode
• silktext (web crawler)
• @6digit/satellite-core
• @6digit/satellite-convex
• @6digit/mnemonics
• @6digit/browser-error-reporter

Eleven packages. All the work of releasing: npm publish, versioning, package.json, documentation, making it work outside my context.

And now? Most sit there. Version 0.x.x forever. Npm purgatory.

But not all. Zontax survived. Zod-subset-parser survived. They’re real technology—Zontax treats Zod schemas as data instead of code, with arbitrary metadata embedding. I use them across multiple projects. They passed the gauntlet: rebuilt multiple times to the same shape, bounded domain, self-driving.

The pattern holds even here. Most open source releases are larvae that should have stayed private. A few are legitimate crosscutting tools that earned their release. The mistake is treating them the same—releasing everything because “why not, it’s free.”

It’s not free. Open source has the same cost structure as products, just without the revenue:

• Second user arrives → same support burden
• Edge cases discovered → same defensive coding
• Breaking changes needed → same backwards compatibility pressure
• Questions asked → same time drain

But worse, because there’s no revenue to justify the time. Just guilt when you don’t maintain it. “Abandonware” shame. The unspoken expectation that open source means “free labor on demand.”

The “just open source it” argument assumes releasing is free and the only cost is the price tag. But the cost was never money. The cost is the second user. Open source doesn’t eliminate that cost. It just removes compensation for bearing it.

The Product Aspiration Trap

The moment you think “this could be a product,” you start building for ghosts.

You write documentation for users who don’t exist. You add features for edge cases you’ll never hit. You create abstractions for flexibility you’ll never need. Your README starts selling instead of explaining.

And the cruelest part: the more “product-ready” it looks, the less likely you are to use it yourself.

Because now it’s precious. It’s investment. You can’t just hack on it—you might break the beautiful abstraction. You can’t pivot—the documentation would be wrong. You can’t throw it away—look at all that work.

The tool ossifies before it ever becomes useful.

Meanwhile, the lunchbreak tool:

• Solves YOUR problem
• Works TODAY
• Can be hacked without guilt
• Can be thrown away without grief
• Evolves at the speed of your understanding

If you catch yourself writing a README before you’ve used the tool for a week—stop. You’ve already lost. You’re building for ghosts.

The Cost Isn’t Production (Anymore)

This is the insight that changes everything: the cost of a tool isn’t building it. The cost is the commitment to more than one user.

This is NEW. This didn’t use to be true.

Before AI, building a sophisticated tool took months. Years. The production cost dominated. You’d think carefully before building because building was expensive. If you invested that much time, of course you’d want users—you needed to amortize the development cost across many people.

The economics made sense: high production cost, so maximize users to justify it.

Now? Building a sophisticated tool: a lunchbreak. Maybe a weekend.

Maintaining that tool for a second user: still a lifetime career.

The production cost collapsed. The maintenance cost didn’t. The ratio inverted.

One user—you—is just using a tool. Two users is a support relationship. The second user doesn’t understand your mental model. They hit edge cases you never considered. They need documentation. They need updates that don’t break their workflow. They need you to answer questions.

The commitment isn’t “releasing.” The commitment is the SECOND USER. And every user after that adds weight.

This is the throughline to the Future Work Mythology. That essay described the death of teams, the death of coordination, the collapse of organizational scaffolding. AI made the individual powerful enough to need no one else.

The second user brings it all back.

The second user is coordination. The second user is the team. The second user resurrects all the scaffolding that AI was supposed to dissolve—documentation, support, backwards compatibility, feature requests, the slow death of your own velocity.

And worse: the second user changes HOW you code.

The Future Work Mythology described fail-fast as a competitive advantage. When failure is cheap, you try more things. You learn faster. You explore solution spaces the enterprise can’t reach because they’re too afraid to fail.

The second user kills fail-fast.

With one user, failure is learning. You break things, you fix things, you move forward. The failure taught you something.

With two users, failure is liability. You can’t break things—someone depends on them. You can’t move fast—you might break their workflow. You shift from exploratory coding to defensive coding. From “what can I learn?” to “what might go wrong?”

This is the death of velocity. Not from lack of skill, but from the weight of commitment.

When building is cheap and commitment is expensive, the economics invert. You should build MORE tools (because building is nearly free) but release FEWER tools (because the second user is ruinously expensive).

I have a tool called 6digit studio. It’s probably the most advanced context management system for LLM interaction in the world. Node-based workflows, fragment reuse, context refinement, OpenRouter proxy integration. It would take months to describe all its features.

I will never release it.

Not because it’s not valuable—it’s incredibly valuable. I use it to write stories, manage complex projects, orchestrate AI interactions. It’s the reason I can do things other developers can’t.

That’s exactly why I won’t release it.

The moment I release it, I stop being a toolmaker and become a tool maintainer. I trade the forge for the support desk. My weapon becomes my job.

Part II: The Two-Sided Arsenal

Tools for the AI

AI is fast but forgetful. Every session starts fresh. Context is expensive. Mistakes compound.

So you build tools that make forgetting impossible:

Regression tests that scream. Not documentation that drifts—executable specifications that fail loudly when violated. The test suite is a wall. Every time I break something, the wall catches me. Every time I fix something, the wall remembers.

Session memory that persists. I built a tool called claude-prose in a lunchbreak. It extracts decisions, insights, and gotchas from my coding sessions with AI. It makes the history searchable. Right now, it has 410 decisions captured across 9 projects. The AI doesn’t remember—but the tool does.

Documentation that runs. Not “here’s what the system does”—that drifts. Instead: “here’s how to GET what the system does.” Documentation for how to use the tools, how to navigate the codebase, how to run the commands that reveal state. The truth is always one command away.

Tools for the Human

You are slow but persistent. You have intuition but limited working memory. You need time for concepts to consolidate.

So you build tools that make comprehension possible:

Visualizations. Ad-hoc websites. Graphical editors. Anything that makes the invisible visible. I have an EDO graph editor in Godot that lets me see mission state machines visually. I could manage them in JSON—but I can’t THINK in JSON.

Pacing mechanisms. Tools that force you to go slow when you need to. I literally have “SLOW AND STEADY” screamed in my CLAUDE.md file because velocity without comprehension is destruction. The human bottleneck isn’t typing. It’s understanding.

Disposable dashboards. When I need to understand something, I build a tool to show it to me. When I understand it, the tool can die. The understanding persists; the tool doesn’t need to.

The Key Insight

These tools aren’t built to “production level.” Why would they be?

It takes a lunchbreak to build a sophisticated tool. Why would I spend a WEEK making it “reusable”? Why would I write documentation for users who don’t exist? Why would I add error handling for cases that will never happen?

If I need the tool again in six months, I’ll rebuild it. The rebuild will be better because I’ll know more. The rebuild will take a lunchbreak because building is cheap now.

The understanding is the value. The code is disposable.

Part III: The Onion

Not all tools are the same. Some should be released. Some must stay private. Some should be thrown away. The skill is knowing which is which.

Picture an onion with five layers:

Layer 1: The Foundation

Languages. Protocols. Paradigms.

TCP/IP. Git. C. And perhaps—a metacircular event-continuation language called Koru that lets programs participate in their own compilation.

Foundational things have gravity. People build ON them. They disappear into the background and become assumed. They create more value than they could ever capture.

Foundational things MUST be released. Holding them back is almost immoral. Like inventing TCP/IP and keeping it to yourself. The foundation exists to be built upon. It doesn’t need selling—it needs existing.

The test: Does this make people MORE capable of making their own tools? If yes, it might be foundational.

Layer 2: Crosscutting Tools

Stable abstractions used across multiple projects. Schema languages. Testing frameworks. Build tools.

These CAN be released—if they pass the gauntlet:

• Rebuilt 3x to the same shape. If you’ve built it three times and it keeps looking the same, the abstraction is stable. If it’s different every time, it’s not ready.
• Bounded domain. Edge cases are finite. You can enumerate them. You can handle them.
• Self-driving. It works without you answering questions. The documentation is sufficient. The errors are clear.
• Clear “done” state. You can define what “complete” means and walk away.

Most tools never pass this gauntlet. That’s fine. They belong in a different layer.

Layer 3: Personal Weapons

Sophisticated tools for YOUR workflow. Context managers. Asset pipelines. Session memory.

These MUST NOT be released. Not because they’re not valuable—because they’re too valuable. They’re your competitive advantage. They’re why you can do things others can’t.

And releasing them would destroy them:

• They require YOUR mental model to use effectively
• They evolve at the speed of YOUR understanding
• Selling them makes them a job, not a weapon
• Supporting them steals time from using them

Others should build THEIR OWN weapons. That’s the whole point. Your weapons won’t fit their hands anyway.

Layer 4: Disposable Tools

Lunchbreak tools. Single-project. Throwaway.

Ad-hoc visualizers. One-off scripts. Test harnesses. Debugging aids.

These should NEVER be released. Not because they’re not good—because releasing them is nonsensical. The rebuild cost is lower than the maintenance cost. The understanding embedded in them is worth more than the code.

No documentation. No abstraction. No guilt when you delete them. They served their purpose. Let them die.

Layer 5: The Work

The actual output. The thing that matters.

The game. The story. The shipped product. The thing people will actually use.

This is what you sell. This is what goes public. Made possible by all the layers above, but the only layer that faces the world.

The tools stay hidden. The work goes public. You charge for the OUTPUT of your toolsmithing, not the toolsmithing itself.

Part IV: The Discipline

Recognizing Which Layer

The skill isn’t following rules. It’s developing judgment. Here’s how:

If you’re writing a README before using it for a week: You’re in the Product Aspiration Trap. Stop. Use it first. Let it prove itself.

If you’ve rebuilt it three times and it’s the same shape: It might be ready for Layer 2. But only if it’s also bounded and self-driving.

If it requires YOUR context to be useful: Layer 3. Personal weapon. Keep it private. Let it grow with you.

If rebuilding would take less time than explaining: Layer 4. Disposable. Don’t even try to preserve it.

If it makes OTHER people capable of making tools: Layer 1. Foundation. Consider releasing it—but be honest about whether it’s really foundational or just useful to you.

The Larvae and the Butterflies

Some tools need to evolve. Most tools should stay larvae.

The temptation is to evolve everything. To make every tool “proper.” To add documentation, abstraction, error handling, tests.

This is death.

Most tools should stay hacky, single-purpose, undocumented. They should work for YOU, today, for THIS project. That’s enough. That’s more than enough.

The rare tool that actually needs to evolve—you’ll know it. You’ll have rebuilt it three times. You’ll see it appearing in every project. You’ll feel the abstraction stabilizing.

Then—and only then—consider helping it become a butterfly.

The Ethical Dimension

Here’s the hard question: If tools are private weapons, are we creating a new class divide? The tool-makers versus the tool-dependents?

Yes. We are.

Let’s be honest about what’s happening. The person who can build tools with AI:

• Solves problems in a lunchbreak that would take a team a quarter
• Builds exactly what they need, not approximately what’s available
• Iterates at the speed of thought, failing and learning constantly
• Compounds their advantage daily—every tool makes the next tool easier

The person who can’t or won’t build tools:

• Waits for someone else to build what they need
• Uses general-purpose tools that are always worse than specific ones
• Depends on tool-makers who (we’ve established) can’t afford to serve them
• Falls further behind every day, because the gap compounds

This isn’t elitism. It’s physics. The feedback loops are real. The compounding is real. The gap was always there—AI just made it visible. Made it infinite.

And here’s the uncomfortable truth: releasing tools doesn’t help.

If I release 6digit studio, I don’t close the gap. I create dependents. People who rely on MY tool, MY mental model, MY maintenance. They don’t become more capable. They become more dependent. And when I inevitably stop maintaining it—because the second user killed my velocity—they’re stranded.

The solution isn’t releasing tools. It’s teaching toolmaking.

If I release Koru—a language that lets you build your own compilers, extend your own syntax, create your own paradigms—I create capability. People who can make their OWN tools. Who don’t need mine.

The ethical release isn’t the application. It’s the foundation. Not the weapon—the forge.

This is why foundational things must be released. They don’t create dependence. They create capability. They teach people to fish in a world where everyone else is fighting over who gets to sell the fish.

The Niche of One

There’s a reframe that clarifies everything: building tools for yourself is serving the niche of one.

The old economics pushed toward general-purpose tools. Production cost was high, so you had to amortize across many users. You built for the average case because you couldn’t afford to build for specific cases.

The new economics inverts this. Production cost collapsed. You can now profitably serve smaller and smaller niches. The logical endpoint is a niche of one—a tool built for exactly your workflow, your mental model, your needs.

This isn’t selfishness. It’s efficiency. The niche of one has zero communication overhead, zero edge cases you don’t understand, zero support burden. Every click matters because you KNOW the workflow. Every feature serves a real need because YOU have the need.

And here’s the thing: between “niche of one” and “general purpose” lies fertile middle ground. The niche of few—a specialized tool for a specific community with specific needs. Small enough that edge cases are bounded. Focused enough that users share your mental model. Committed enough that every click matters.

This is viable now in a way it never was before. Not “build for everyone” but “build for exactly these 500 people who do exactly this thing.”

The niche of one teaches you how to build for niches. Every personal weapon is practice for the specialized tool that might—someday, if it passes the gauntlet—serve a niche of few.

But that’s a future essay.

Part V: The Throughline

The Future Work Mythology described a world where the individual becomes powerful enough to need no one else. Where coordination overhead disappears. Where the scaffolding falls away and what remains is the work itself.

This is how you live in that world.

Build constantly. Tools are cheap now. Build a tool for every problem. Build tools to understand problems. Build tools to check if your tools are working.

Release rarely. The cost isn’t building—it’s commitment. Every release is a potential job. Every user is a potential support ticket. Guard your time like the weapon it is.

Know your layers. Foundation, crosscutting, personal, disposable, work. Know which layer you’re in. Act accordingly.

Stay honest. The Product Aspiration Trap is seductive. “This could be big.” “People would pay for this.” “I should add documentation.” Feel the seduction. Reject it. Build for yourself.

Ship the work. The tools stay hidden. The work goes public. You’re not in the tool business. You’re in the OUTPUT business. The game ships. The story ships. The product ships. The tools are how you get there—not the destination.

The apes who could use bones dominated. Then the apes who could shape bones dominated. Then the apes who could forge metal dominated.

Now the apes who can make tools with AI will dominate—not because they’re smarter, but because they’re building their own weapons while everyone else waits for someone to build weapons for them.

Don’t wait.

Build your arsenal.

Keep it private.

Ship the work.

This is the companion piece to “Future Work Mythology: The Complete Essay.” That piece describes what’s dying. This piece describes what to build instead. Together, they form a manual for the age that’s already here.

Co-authored by Human and Claude. Written using the very tools it describes—tools you’ll never see, tools that will never be released, tools that made this possible.