About the publisher
Asaboro
Daniel.
I’m a software developer, DevRel practitioner, and writer. I build tools for developers and agents, then write to understand the systems—and the people—around them.
The short version
I did not grow up with a neat plan to become a software developer. I arrived through words.
Before I wrote code, I spent two years doing content marketing for SaaS companies. I learned how software is positioned, how companies explain what they make, and how often the explanation collapses the moment a real person tries to use the product. In April 2023, I started learning to code because describing other people’s systems was no longer enough. I wanted to understand the machinery.
That move did not replace writing. It changed what I could write about. Code gave me a more honest relationship with technical claims. Writing gave me a way to inspect the assumptions inside the code.
I didn’t leave writing to become a developer. I learned to build so I could understand what was worth writing about.
What I work on
The projects change. The question underneath them doesn’t.
How do we give people and intelligent systems more capability without making the underlying system impossible to understand, trust, or control?
Agent infrastructure
Aegis
Wallet analysis and developer tooling built around MCP documentation, reusable skills, and a JSON-first command line.
View the work ↗
Controlled agency
Leash
An exploration of how capable AI systems can act inside explicit operational and permission boundaries.
View the work ↗
Programs & research
Solana work
Programs, security experiments, standards, educational work, and technical writing across the Solana ecosystem.
View the work ↗
Developer experience
Documentation
Documentation systems and developer education that treat explanation as part of the product—not cleanup after launch.
View the work ↗
The longer version
I build across borders.
My public work crosses Solana programs, protocol research, Web3 security, developer documentation, local AI, MCP servers, agent skills, and small products that begin as questions.
That range can look scattered if you organise it by technology. I organise it by the problem: making powerful systems usable without hiding the trade-offs that make them powerful.
Blockchain made incentives and trust impossible to ignore. DevRel made the distance between an internal product model and a developer’s lived experience visible. AI agents made authority, provenance, and operational boundaries urgent.
I write in public to sharpen the work.
My essays use metaphors because technical systems need models, not just definitions. I have written about Solana slashing through the discipline of a hostage-rescue team, Web3 security through the failure of the Maginot Line, and developer writing as part of the product itself.
The metaphor has to survive the details. If it cannot explain the pressure points, incentives, and failure modes, it is decoration. If it can, it gives the reader something durable enough to carry into the next problem.
This newspaper is where I keep that practice: field notes from whatever I am building, breaking, documenting, or trying to see more clearly.
Working principles
- 01
Build close to the problem.
The fastest way to lose reality is to polish an abstraction before it has met a user, a failure, or an inconvenient constraint.
- 02
Explanation is part of engineering.
If a system cannot be explained without reproducing the team’s private context, the system is not ready to travel.
- 03
Capability needs visible boundaries.
Tools become trustworthy when people can see what they may do, what they did, and how to recover when execution stops halfway.
- 04
Publish the unfinished thought.
Writing is not a victory lap after certainty. It is one of the instruments used to reach a better question.
Find me