The Architecture of Choice

When I launched Pregnancy Power Hour, the initial ad spend was exactly $50 a day, and it took forty-eight hours to realize I was targeting the wrong audience entirely. I had built a beautiful landing page and a backend that could handle thousands of concurrent users, but I hadn't spent enough time deciding who the product was actually for. The technical build was a success, but the business decision was a miss. In the new world of software building, where agents can generate a functional repository in minutes, the bottleneck has shifted from the "how" to the "what."

The cost of building has collapsed, but the cost of being wrong remains as high as it ever was. If you can build anything, the only thing that matters is building the right thing. This requires a level of discipline that most founders overlook in the rush to see something live on a URL. Before I open a terminal or look at a line of code, I run every idea through a series of filters designed to kill the project before it costs me time or money.

The Market Thesis

Every product in the Total Ventures portfolio starts as a bet. I don't look for gaps in the market so much as I look for problems I understand deeply from my own life or my time at places like Fender. The F1 Formula didn't start because I wanted to build a sports app; it started because I was frustrated with how difficult it was to track specific data points during a race weekend.

The decision of what to build is a function of taste and judgment. You have to be able to look at a crowded market and see where the existing solutions are failing to respect the user's time or intelligence. I prefer to build in categories where the competition is bloated and slow—where a single operator with a better system can provide more value than a funded team of thirty. If the thesis doesn't hold up under a simple "why now?" analysis, the project stays in the notes app.

Unit Economics as Architecture

I learned the hard way that a product with bad margins is just a hobby that eventually makes you tired. In my studio, the financial rails are part of the system design. I look at the payback period and the margin before I look at the tech stack. If a product requires a massive user base to break even, I won't build it. I am looking for cash-flowing assets that can run with minimal intervention once the initial engine is built.

This means choosing revenue models that reflect the value being provided. Whether it’s a subscription for a tool like Inky or a one-time purchase for a specialized resource, the money has to make sense at a small scale. I want to know that if I only have one hundred customers, the business is still healthy. This focus on profit over vanity metrics allows me to keep the studio lean and my calendar open for the things that matter, like spending mornings with my son, Jupiter.

The Sequence of Shipping

Once the "what" and the "who" are settled, the next decision is the order of operations. Most builders try to launch the version of the product that exists in their head six months from now. I prefer to launch the version that proves the core bet today. This isn't about cutting corners; it's about reducing the feedback loop.

When I’m building a new engine within ShadowBrain, I start with the smallest possible unit of value. If the agentic workflow can’t handle one specific task perfectly, there is no point in building the orchestration layer to handle ten tasks. The sequence is always: prove the value, automate the delivery, then scale the traffic. If you flip that order, you end up with a very expensive machine that nobody wants to use.

Building for Leverage

The final decision before code is how the product will fit into the existing studio ecosystem. I don't build isolated projects; I build components that can be reused across the entire portfolio. The monorepo I’ve architected allows me to ship a new brand with the same financial rails, authentication, and deployment logic I used for the last one.

This is where the real leverage lives. Every hour I spend making a decision on one product should ideally benefit the other three. This compounding effect is what allows one person to maintain a portfolio of real products without burning out. It’s not about working more hours; it’s about making sure the decisions you make today are still doing work for you a year from now.

The studio model works because the owner is willing to be the one who says no to a good idea to make room for a great one. Every launch is a risk, but when you front-load the decisions, you ensure that the risk is one you can afford to take. The weight of building something to keep is felt most in these early choices, long before the first commit.