Helios.
My personal AI
operating system.
What happens when a fintech product marketer with no engineering background decides that talking about AI isn't enough, and builds one instead.
Active Build · Phase 5
The problem I couldn't ignore
I kept getting the same feedback. Different companies, different recruiters, different roles, but the same underlying message: strong on strategy, strong on fintech, strong on domain. But not technical enough. Couldn't build. Did not have engineering credibility. Could market AI but had not shipped anything.
That feedback is fair. It's also fixable. So I decided to fix it.
Not by taking a course. Not by getting a certification. Not by adding keywords to my resume. I bought a Raspberry Pi 5, put it on my desk, and committed to building something real until the feedback was no longer true.
"I didn't want to watch tutorials about AI. I wanted to understand what it actually takes to build an AI system that works in production."
The goal wasn't to become an engineer. I'm a product leader and I intend to stay one. The goal was to develop genuine fluency in AI systems, the kind that comes from building, breaking, recovering, and building again. The kind that changes how you think about product decisions, adoption challenges, and what it actually means to ship something that uses AI reliably.
What started as a learning project became something larger. It became Helios, a personal AI operating system that I'm building to grow alongside my career, and eventually to help run it.
How it actually got built
I didn't come into this project with a plan. I came in with a Raspberry Pi, an SSH tutorial, and a list of things I wanted to understand: Linux, Docker, AI engineering, local LLMs, DevOps, software architecture. The phases emerged from the work itself.
broke everything.
On naming things
The infrastructure project has a second name: BlueDemonPi. Most people won't recognize the reference immediately, which is part of the point.
Blue Demon, El Demonio Azul, was one of the most iconic figures in lucha libre, the Mexican wrestling tradition. He wore a silver and blue mask his entire career. Never took it off in public. The mask wasn't a costume, it was an identity. An alter ego built to do something extraordinary under a different name.
I named the project after him because I'm doing something similar. Danny Del Toro, fintech product marketer, is the public identity. BlueDemonPi is the alter ego, the side of the work that exists in the terminal, in Docker containers, in Python packages, in model registries. The side most people don't see.
Helios is the name I gave the intelligence running on top of that infrastructure. The sun. Something that generates light and makes other things visible. That felt right for what I'm trying to build.
I learned it by breaking things and fixing them.
Where Helios is going
The current version of Helios can route a query to the right local model and return a response. That is a foundation, not a destination. What I'm building toward is a personal AI operating system that can manage knowledge, automate workflows, and operate with increasing autonomy over time.
Each feature will be delivered as a complete vertical slice, code, tests, CLI integration, documentation, and a commit, rather than incremental fragments. That discipline is intentional. It is how production software gets built.
"The end state is an AI that knows my work as well as I do and can help me operate at a level I could not reach alone."
What building Helios changed about how I think about AI
I'm not trying to become a software engineer. I'm a product marketing and growth leader with 14 years in fintech, and that is exactly what I intend to be. But the best product leaders in AI right now are the ones who understand the systems they are working with from the inside, not just conceptually, but practically.
Building Helios changed how I think about AI product decisions. When I discovered that one of my local models hallucinated personal information and another produced uncontrolled reasoning loops, I didn't just note it. I translated those failures into system requirements: grounding, provenance, explicit unknowns, reasoning limits. That's the same process product teams at Anthropic, Cursor, and every other serious AI company go through every day.
I know what it feels like to debug a Docker network issue at 11pm because a volume mount broke. I know why API-first design matters for a routing layer. I know the difference between a model that is fast and a model that is reliable. I know what it means to ship a complete feature slice with tests and documentation rather than a half-built prototype — that's a meaningful distinction.
The answer to 'can you build?' is now straightforward. But what changed more was how I think — about reliability, routing, failure modes, and what it actually takes to ship an AI feature that works in production rather than just in a demo.