Log

I've brought many products from idea to market across multiple segments and have been close to every part of launch: prioritization, GTM strategy, late nights polishing features. But this is the first time I've done the actual greenfield environment setup and deployment. I'd assumed it would be relatively straightforward since I'd seen it done so many times, so I knew what the process should look like. While that's true, the doing is another matter. It's the BJJ version of watching a veteran black belt roll: the sequence looks smooth until you're the one on the mat, and you find out how much detail and technique you hadn't even registered. The gap between what I assumed and what's real is humbling, and the part I find most compelling.

I'm comfortable with local development for fast feedback and full-stack control; with prototyping tools such as Replit, Claude Code Artifacts, etc.; and with existing production systems that are stable and well-instrumented. Syscribe is in none of those states right now, and this is an education. Bugs that stayed silent on my machine only surface once the services are split across environments, environment variables that lined up locally stop lining up, and several of these go wrong at once, so a single symptom rarely points to a single cause. Most of the work is figuring out which failures are real and which are just downstream of the others.

Staging is nearly there. If the pace holds, I should have full production running within a week or so.

Reading other reviews of this book, I was struck by several reviews stating that the novel was the wrong format for what is, effectively, a technical management book. I disagree with that perspective. The novel allows the reader to see the human impact of those situations and decisions because people matter. The narrative approach helps everyone remember that while the principles and perspectives around processes are critical to a successful project or business, they are only important to the extent that they help the employees or customers of that business succeed.

The first third of The Phoenix Project was an exercise in re-living chaotic work experiences. For example, during my second week as VP of Product Management our entire payments system went down, mimicking the crucible Bill is subjected to immediately after his promotion. We sorted out the payment issue quickly, not because of heroics, but because I'd been in that situation enough times to stay calm. That recognition was the same thing the first few chapters kept dredging up.

Two things really stuck with me. The way Bill treats and interacts with his subordinates, peers, and superiors is an ideal textbook for someone at any managerial level in any organization: understand the business needs, understand the people and technology issues involved, be a good ancestor to those who will come after you by being a good steward of process.

And, the enumeration of the types of work and modes of process improvement is a valuable formalization that I'll use going forward. It is certainly valuable regardless of the business vertical (the conversations with Erik should make it apparent that the authors didn't want to consider IT exclusively). Sure, the technology issues they experience in the book are a decade out of date, but the disruption and the resulting disorganization are timeless. So is cleaning up the messes they make.

I got a notification on my Garmin watch while in the middle of a set of heavy squats at the gym. It was a Claude Code session with /remote-control enabled asking me to approve a bash command. I approved the command directly from my watch and continued my workout.

There's no question about the immediate-term efficiency gains—the fact that I could unblock an AI agent building features while I was at the gym is the future that this tech has promised.

I used to think about work problems while out for a run, but I wasn't able to do anything about them until I got home; there is value in the perspective and creativity that rumination creates.

Is this ability to be constantly producing a net positive, or will it increase the amount of burnout (already at record levels) that we're seeing as a society because it creates an expectation? I don't know. But I fear it won't be good for work or people in the long run because it is removing the space and time we all need to make our best decisions.

Syscribe staging is now web-hosted—something I can open in a browser and click around, instead of running only on my laptop. Getting there cost the better part of a few days, and the lesson wasn't in any single fix. It was that one symptom can sit on top of a stack of unrelated causes, each masquerading as the last.

Every failure looked identical from the outside: something that should have had a value was reading as undefined. A sensitive flag on a public key. A production auth instance refusing to run on a preview domain. An API verifying tokens against the wrong secret. And the worst one—a web app that, missing its API URL at build time, quietly fell back to localhost:3001, so the deployed site was cheerfully trying to reach a server on my laptop. That one failed by succeeding at the wrong thing.

Four distinct bugs, one symptom. Each time I fixed one, the next surfaced looking the same, and the tempting read was "my fix didn't work" rather than "I've peeled off a layer and found another."

What actually closed it wasn't the four patches. Underneath them were a couple of decisions we'd made for simplicity that turned out to be directly opposed to what the services require. We'd run a single auth tenant across every environment; Clerk's production instances flatly refuse to operate on a preview domain. We'd leaned on a localhost default so local dev needed no extra config; a deployed build has no localhost to fall back to. Neither conflict was visible until we'd dug past the identical symptoms to the root—the sameness of the failures is what kept the architectural problem hidden.

The fix was structural: split the auth tenants by environment, and make the build refuse to run without a real API URL instead of guessing one. The boring artifact that records it—a short doc saying which secret lives where—turns "why is staging down again" into a lookup instead of an investigation.

I finalized Caffeinated today with only a couple of minor changes, so it's now available for anyone to build and run on GitHub.

The build itself was relatively straightforward, but the quirks of Swift and Xcode were a departure from TypeScript in VSCode or SQL in DBeaver. The most interesting difference was how Xcode buries the built .app deep in DerivedData, outside the project folder entirely, instead of somewhere human-findable—that's a product decision I don't understand.

While I enjoyed the nature of this book (survey-style books that explore a thorny question are some of my favorites), Pollan brushes by a major tension that's extremely relevant today: can AI truly be conscious? He states several times that the answer to that question is "no" or at least "not any time soon," but does so in a way that feels a bit disingenuous to a book otherwise intentionally critical of most theories. While he and the various scientists and philosophers he cites are willing to extend the possibility of consciousness, or at least sentience, along a broad biological spectrum (plants and single-celled organisms) and across several substrates (not just brains can be conscious), his prevailing conclusion is that a machine could still not be conscious. If the substrate doesn't matter, then it doesn't matter at all. Saying otherwise creates an arbitrary line that carbon-based systems can have consciousness, but silicon-based systems can't. Following those arguments to their logical conclusion, we end up committing to biological essentialism, property dualism, some story about why this particular arrangement of carbon is special in a way silicon can't replicate.

I recognize that this is the "hard problem" of consciousness, and that as a metaphysical phenomenon it may be structurally unsolvable given that we can only evaluate others' consciousness via subjective inference. Pollan's relative lack of criticality on this point is a low point in an otherwise solid book.

Three threads I'm pulling on next: William James on the philosophical limits of studying a stream from inside it; Damasio on feelings and the body as constitutive of consciousness and how it relates to trauma and experiences as somatic memory per van der Kolk's The Body Keeps the Score; and Kuhn's A Landscape of Consciousness.

While verifying Syscribe's staging deployment on Railway last week, Google Cloud blocked Railway's entire account mid-debug. The platform went down for hours and left our staging environment in a half-broken state we couldn't fix because the dashboard itself was degraded. The proximate issues on our side were small (an unset env var, a hardcoded port mismatched against the routing config), but they were hard to diagnose against a flaky control plane. Six hours on what was probably thirty minutes of actual fixable work.

Managed services like Railway, Vercel, and Neon let a solo founder ship at a pace self-hosted infrastructure can't match. The cost is that when one degrades, you lose the observability and recovery options you'd have if you owned the substrate. A single-vendor PaaS built on a single cloud creates concentration risk that compounds in exactly the moments you need the platform most.

Longer-term, Syscribe should be portable enough to fall back to another cloud when a single provider goes down. Not today, not at this stage, but it belongs on the list.

The site is live and the project notes are here.

Currently working through the actual deployment of the product to live production and staging environments instead of just local development. There have been a lot of decisions about when to build versus when to use services. For the most part, I've decided to use existing SaaS/PaaS services since the free tiers are often sufficient for the current state, and every layer except the product itself is already a commodity. One might think this would be the easiest part (how hard could it be to set up a Railway or Neon?), but it's proven to be pretty brutal for two reasons:

1. There is a lot of infrastructure required to get Syscribe to actually work as a product; I think I'm at 10 distinct services for infrastructure between web hosting, worker management, data persistence, etc.

2. Getting all of that infrastructure to work together is an education in credential management and surgical code changes.

All this has me thinking that there's another business opportunity here: something less all-inclusive than Replit or Bolt, but more comprehensive than the one-business-per-service experience that I'm using. This may be worth exploring after Syscribe.

I read a lot of science fiction and horror, but this twist was excellent — strongly foreshadowed and yet a complete surprise. And I am not just saying that because I'm an Expanse diehard (though, admittedly, I am).

Part geology book, part memoir that talks about one of my favorite meta themes: how we can learn about something from something (seemingly) entirely unrelated. In this case, Bjornerud uses geology as a complex metaphor for the trials and triumphs of life, and how deep study allows us to build connections that we could never otherwise construct.

We're about to launch an entirely new product to serve a market segment that is currently not served at all. Like any new product launch, the desire to "build until it's perfect" is a siren's call that has to be ignored for all the right reasons. Especially since, when building product, you know all the gaps, all the things you'd like to see, all the experiences you'd like a user to have.

This is probably the single biggest challenge I experience when making things: not the desire to get it right (since we'll do that in the long run, correctly), but the desire to be perfect out of the gate.

But we have to have the discipline to build, test, learn, and iterate.

Regardless of your opinion of him as a person, there is no denying that Craig Jones is changing the sport of Brazilian Jiu-Jitsu. I find the approach compelling: "Here's how you've been taught to do the sport. Here are better ways to achieve the same goals that had not been considered because they weren't part of the teaching lineage." I love the idea of looking at the current paradigm with all its own internal structures, rules, and tribal expectations, and dismantling those expectations to achieve goals in a brand new way. It's a pattern I am drawn to—in BJJ, in product, in how I want to build Syscribe. Inherited structures aren't the same as good structures.

I raced the Craters Classic in Taupo and it was almost certainly the worst race of my life. I didn't focus enough on recovery since I was planning on training through the race and was over confident based on my win at the Volcanic Epic a couple of weeks prior. On paper, this should have been an excellent course for me: 50km, a reasonable amount of punchy climbing, lots of technical work. But it just didn't work out on race day. The lesson—which I already knew, but apparently needed to learn again: way more sleep the week before a race.