Anahata grew out of a long-running fascination with how things work, and a slightly more complicated fascination with why they so often do not.
My first real encounters with technology were physical. I grew up around electronics, old machines, and the particular kind of curiosity that comes from opening something up before you fully know how to put it back together. A VCR, a circuit, an old computer: these were not just objects, but invitations. They suggested that the world had layers, and that with enough patience you could learn to move between them.
Coding arrived early and felt like a natural extension of that impulse. It was a way to build little worlds that actually did something. By my teens, programming had already become more than a hobby; it was a craft, a language, and eventually a way into work. I took on technical roles young, moved quickly through computer science, and found myself drawn to the places where software was not just an implementation detail but the thing that changed what a person or a team could do.
For a while, that meant moving fast through increasingly complex technical environments: mobile development, AI research contexts, startups, consumer products, engineering leadership. I learned how to ship, how to debug under pressure, how to translate vague ambition into something a team could build, and how to keep enough structure in place that the whole thing did not collapse into heroic improvisation.
I also learned that technical competence, while necessary, is nowhere near sufficient.
That lesson landed hardest through startup work. A mobile payments company taught me plenty about product, engineering, leadership, and markets, but it also taught me about the limits of effort applied in the wrong conditions. Some problems cannot be solved by writing better code, staying up later, or making the architecture more elegant. Funding matters. Geography matters. Timing matters. Team dynamics matter. So do incentives, trust, attention, and the thousand informal decisions that never make it into a roadmap.
That experience changed the shape of the questions I ask. I became less interested in whether a system could be built and more interested in whether it could become useful inside the messy reality where it was supposed to live.
Later, working in more mature startup environments, including companies shaped by Silicon Valley’s product culture and the consumer wellness space, gave me another kind of education. I saw how much leverage sits at the intersection of engineering, psychology, design, and timing. A product is not just a bundle of features; it is a bet about human behavior. A team is not just a collection of skills; it is a coordination system. A good tool does not merely perform a task; it changes what people notice, what they repeat, and what they believe is possible.
In hindsight, many of my best instincts as an engineer came from the same place as some of my worst working habits: an urge to see the whole system at once, to connect domains that other people keep separate, to move quickly from pattern to prototype. The trick has been learning how to turn that into a practice rather than a weather system.
Anahata is part of that practice.
It is not a conventional agency, and it is not quite a personal blog with a services page attached. I think of it as an AI-native engineering practice: personally stewarded, technically serious, and built around the idea that a small, thoughtful system can have outsized leverage when it combines software engineering, knowledge architecture, workflow design, and the careful use of AI.
The careful part matters.
I am excited about AI, but not because it lets us decorate old workflows with new buttons or pretend that judgment has become obsolete. The interesting opportunity is quieter and more demanding than that. AI gives us a new material to build with: one that can help structure ambiguity, compress research, surface patterns, draft, critique, simulate, and coordinate. Used well, it can make expertise more available at the moment it is needed. Used poorly, it can produce confident mush at industrial scale. We have all seen the mush.
So the work here is about designing systems that keep humans in the loop without making the loop ornamental. Systems that help people think more clearly, move with less friction, and preserve the parts of work that require taste, context, responsibility, and care.
The name Anahata comes from the heart, but not in a soft-focus, wellness-brand sense. To me it points to integration: the place where different kinds of intelligence meet. Technical and human. Analytical and intuitive. Strategic and hands-on. The part of the work that can be measured, and the part that has to be felt before it can be named.
That is the territory I am most interested in now. Not technology as spectacle, and not automation as a substitute for understanding, but practical systems that help people and organizations become more capable.
This portfolio is a record of that direction: the tools, essays, experiments, technical notes, and working theories that make up Anahata. Some pieces will be polished; others will still have the smell of the workshop on them. That is intentional. I would rather show the evolution of the practice than pretend it arrived fully formed.
The work is still moving. So am I.