How I build — the operator playbook

When I moved to Mexico to focus on the birth of my son, Jupiter, I had exactly ninety days to automate the deployment cycles for three separate brands. That constraint forced a clarity that a comfortable schedule never could. I wasn't just building software anymore; I was architecting a digital studio that could breathe while I was away from the keyboard.

Being a creative-type who builds software means I often have more ideas than hours. For years, I approached each project as a unique island. I’d spin up a new repository, configure new database instances, and rewrite the same authentication logic I had written a dozen times before. It was a craftsman’s approach, but it wasn't an operator's approach. To manage a portfolio that includes Inky, Pregnancy Power Hour, and The F1 Formula, I had to stop building projects and start building a machine.

The shared architecture

The core of my playbook is the monorepo. Every brand I own lives under one roof, sharing a single engine. I learned the hard way that maintaining three different versions of a billing system or a mailing list integration is a recipe for burnout. By consolidating the infrastructure, a fix I push for one product automatically improves the others.

In this model, the "studio" is the platform, and the brands are the apps running on top of it. I use a shared library for UI components, a unified data layer, and a single set of financial rails. This doesn't just save time; it reduces the cognitive load of switching contexts. When I move from working on F1 data pipelines to pregnancy wellness content, the underlying environment remains the same. I am always in my own shop, using my own tools.

The shift in leverage

The traditional way to scale a software company was to hire people. You’d find a developer for the frontend, an engineer for the backend, and a manager to make sure they talked to each other. Today, that overhead is a choice, not a requirement. The cost of generating code has collapsed, but the cost of distribution and taste has remained high.

I operate using agentic engineering to handle the high-volume, low-judgment tasks. I’ve built a series of agents that handle the "ops" of the studio—monitoring server health, reconciling daily transactions, and drafting initial research reports for new features. These aren't just scripts; they are specialized loops designed to escalate only when a decision requires human intuition. This allows me to keep the team size at exactly one, while maintaining the output of a much larger organization.

Judgment over code

Fourteen years as a working jazz guitarist taught me that the best notes are the ones you don't play. Software is the same. The temptation for a solo founder is to build every feature a customer asks for or every shiny tool that hits the timeline. An operator’s job is to say no to almost everything so that the few things that remain are excellent.

I evaluate every new feature through a simple lens: does this increase the complexity of the machine, or does it increase the value of the asset? If a feature requires a new type of database or a manual weekly check, it usually gets cut. I prefer systems that are robust and "boring" because boring systems don't break at 3:00 AM when I’m with Brittany and Jupiter. The goal is a portfolio of cash-flowing products that run on a predictable, repeatable rhythm.

The operator’s rhythm

Shipping isn't a frantic event; it’s a scheduled output of the system. I don't believe in "the grind" or the performative urgency that defines much of the software world. I spent thirteen years in the Army National Guard, and that experience taught me that discipline is the only way to survive a long campaign.

My workday is structured around high-leverage blocks. The mornings are for deep work—writing code or architecting the next agent loop. The afternoons are for the "manager" tasks—checking the logs the agents escalated and reviewing the numbers. By 4:00 PM, the work is done. If the system is designed correctly, it doesn't need me to hover over it. It is an asset that works for me, not a job that I happen to own.

This transition from builder to operator is a deliberate choice to prioritize profit and peace over headcount and hype. I am not interested in building a "rocket ship" that might explode; I am building a studio that lasts. The work is quiet, the growth is steady, and the system is the moat. At the end of the year, a clean P&L and a quiet calendar are the only metrics that prove the system works.