Day 7 of Building HYNA-Stage: I Published Two NPM Packages From a $150 Phone

Day 7. When you decide to build enterprise-grade developer tooling entirely on a $150 Android phone using Termux, you accept a certain level of chaos. You battle the "Termux Poltergeist" (where the terminal buffer corrupts your source code). You wrestle with strict API gateways. You debug spawn EN

OENT errors at 2 AM. But then, you push through. And you ship. Today, I am incredibly proud to announce that two core HYNAWEB packages are now live and publicly available on the NPM registry, built, tested, and published entirely from my mobile device.

npm install -g @hynaweb/stage) A CLI that provisions isolated, ephemeral Firecracker microVMs for AI coding agents in exactly 5.1 seconds. By utilizing a "Warm Pool" architecture orchestrated via Supabase Edge Functions and the E2B SDK, we completely eliminated cold starts. No Dockerfiles, no YAML, no credit card required. npm install -g @hynaweb/kavlr) A fail-closed, AI-powered terminal leash for autonomous agents.

Instead of relying on fragile text-based regex guards, KAVLR intercepts execution and grades the semantic action using a rigorous 90-article Constitutional AI framework. If an agent attempts a destructive or exfiltration action, KAVLR blocks it at the shell level with a 0/100 score. Publishing from a mobile environment is not for the faint of heart. But it forces a level of discipline, optimization, and lean architecture that is hard to learn on a $3,000 MacBook with unlimited resources.

Every byte matters. Every API call is scrutinized. Every line of code has to be resilient. The bugs were brutal, but we gave them names, defeated them, and shipped the code.

Try them out and let me know what you think: Deploy in 5.1s: npm install -g @hynaweb/stage Secure your agent: npm install -g @hynaweb/kavlr Join the Jam: hackerstage The noise doesn't matter. The code ships. Onward to Day 8. 🐯☁️🚀

Every byte matters. Every API call is scrutinized. Every line of code has to be resilient. The bugs were brutal, but we gave them names, defeated them, and shipped the code.

Day 7 of Building HYNA-Stage: I Published Two NPM Packages From a $150 Phone

Key Takeaways

Related Articles

Authorization Is a Runtime Decision, Not a One-Time Permission

We changed a core rule two weeks in. No service had to be rewritten.

Mind, Body... Agent?

What White Box Testing Misses When Your Code Talks to External Services

Discussion

Day 7 of Building HYNA-Stage: I Published Two NPM Packages From a $150 Phone

Key Takeaways

Related Articles

Authorization Is a Runtime Decision, Not a One-Time Permission

We changed a core rule two weeks in. No service had to be rewritten.

Mind, Body... Agent?

What White Box Testing Misses When Your Code Talks to External Services

Discussion

Related Articles

Dev.to
Authorization Is a Runtime Decision, Not a One-Time Permission
An AI agent shouldn’t receive permanent permission just because its initial task looked safe. Agents rarely follow a fixed path. They retrieve new information, select tools, update their plan, and decide what to do next. Each step can change the risk of the action that follows. A request to “prepare

Dev.to
We changed a core rule two weeks in. No service had to be rewritten.
On 12 October 2026, two weeks into building DynoInvoice, the owner sent one line: "The system must access the database in one unified way." At that moment, 29 production files in six shared library modules talked to the database through plain JDBC, which the standards had allowed until then. One of

Dev.to
Mind, Body... Agent?
It's tempting to think of an agent as the model. When it does something great, the model is smart. When it does something dumb, the model is dumb. So you go looking for a newer model or a better prompt. Although a better model or prompt may help, this is just not the case. The brain is the large lan

Dev.to
What White Box Testing Misses When Your Code Talks to External Services
White box testing gives you visibility into the code. You can see which branches execute, which paths get covered, which conditions trigger which outcomes. For logic that lives entirely within a service boundary, that visibility is genuinely useful. The problem shows up the moment your code talks to