Field Guides go deeper than the blog - long-form, hands-on walkthroughs that take one topic from start to finish, gotchas and all. The kind of thing I wish I'd had the first time I hit the problem.
A standalone playbook for a fractional or new CTO's first 90 days, the 30/60/90 framework, listening tour, scorecards, and the scope-of-work and decision templates that make an engagement work from day one.
Deploy and run real apps on one VPS with Coolify, no Kubernetes, no serverless. Self-hosted PaaS, databases, TLS, backups, and zero-downtime deploys on a box you own.
Every piece of good advice about running a business alone used to come back to one constraint: there is one of you, and you have a fixed number of hours. Don't build software that needs support, because questions scale with customers and you can't hire. Sell content instead, because content is finished once you publish it. That advice was right, and it stopped being right. This is a guide to building a small, durable business on your own in 2026, using leverage that didn't exist when most of the advice you've read was written. One person plus a fleet: a handful of narrow, well-guarded agents handling the parts of a company that used to need headcount, run by someone who stays close enough to the customer to notice when it's going wrong. It covers choosing what to build now that the content-versus-software split has been rearranged, what a fleet actually costs in money and attention, the parts of the job you must never delegate, pricing when your marginal cost of delivery approaches zero, and the specific ways this fails. It includes the year I grossed ten thousand dollars, because a version of this genre that skips to the good part is worse than useless. _This is a living document and will be updated as the tools and the economics keep moving._
Build a real eval suite from zero with Evalite, deterministic checks, LLM-as-judge, and the data flywheel that turns user feedback into a system that improves itself. The unit tests for probabilistic software.
A build-along on writing, structuring, and evolving the context files (AGENTS.md, CLAUDE.md, constitution.md) that steer coding agents. From a blank file to a living system that compounds every cycle.
Build one real app start to finish on Astro + Datastar + Directus, a hypermedia-first stack with a CMS backend, SSR endpoints that stream, and no SPA framework in sight.
You built one agent that knows you cold. Its own personality, a memory that survives, skills it runs your way. It's a great employee. It's also still one employee, doing one thing at a time, waiting on you to hand it the next task. This guide is about the next move: turning that single agent into a coordinated fleet that plans, executes, and monitors real goals while you supervise instead of operate. It's the deep-dive sequel to [Building Your Agentic OS](/guides/building-your-agentic-os), where that guide ended by pointing at the horizon, this one walks the whole distance. We build it on Hermes, because Hermes already ships the hard parts: profiles (every agent a full citizen with its own identity and memory), a durable kanban board that coordinates them, a decomposer that routes a dropped-in goal to the right specialists, and a way to package a whole agent as a git repo and hand it to your team. Concrete throughout, honest about the sharp edges, and built so the foundation you already laid is exactly what scales up.
Two people can use the exact same AI agent and get wildly different results. It's almost never the prompting. One of them built a system underneath the tool (a layer that gives the agent a persistent identity, a real memory, and a set of skills it runs the same way every time) and the other is still re-explaining themselves at the start of every session. This is a field guide to building that system, in three moves. First, the OS itself: a plain-files architecture you can stand up this afternoon on whatever agent you already use, built around three pillars, personality, memory, and skills. Second, the pivot, graduating that static setup onto Hermes, Nous Research's open-source, self-hosted agent, so the files stop being a brief you read aloud and become a teammate that runs on its own. And third, where it's all heading: coordinating many agents to plan, execute, and monitor real goals, with the orchestration, shared memory, and governance that make a true agentic OS. Everything here is portable by design, and you build it one working piece at a time, starting with a single agent that actually knows you.
"Fractional CTO" has become one of those titles that means everything and nothing. If you're a founder, it's often unclear what you're actually buying, a part-time CTO? a fancy consultant? a cheaper hire? And if you're an experienced engineer, it looks like an appealing way out of full-time employment, but with no real map for how to do it well. This guide is for both of you, a straight, advisory look at what the role actually is, when a company needs one, what it costs in 2026, and the AI and agentic-team leadership that increasingly defines the job.
For about two years, my default stack for interactive server-rendered apps was HTMX for the network and Alpine.js for the sprinkles of client state. It worked. It also meant I was running two libraries that didn't know the other existed, and I was the glue holding them together. I [wrote about why I finally switched to Datastar](https://rogerstringer.com/blog/why-im-migrating-from-htmx-alpine-to-datastar). That post is the *why*. This one is the *how*. It's the guide I wish I'd had: a comprehensive, pattern-by-pattern map for moving an HTMX + Alpine app over to Datastar, with a bias toward Astro because that's where I live. If you've got an existing app and you're wondering whether the migration is a weekend or a quarter, the short answer is: smaller than you think, and you can do it one feature at a time. Let's get into it.
Datastar is a hypermedia framework that gives you the backend reactivity of HTMX and the frontend reactivity of Alpine.js in a single, lightweight library. If you've been using HTMX and Alpine together, you know the dance: HTMX handles your server requests and DOM swaps, Alpine handles your client-side interactivity, and you're constantly context-switching between two different mental models. Datastar unifies both into one cohesive system using standard `data-*` HTML attributes and Server-Sent Events (SSE). ### One library to rule them all. In this guide I'll walk you through the building blocks of Datastar, show you how it compares to the HTMX + Alpine combo you already know, and demonstrate how to build interactive web applications with Astro on the backend. I will assume you're familiar with HTMX and Alpine.js concepts. Learn more on the official website at [https://data-star.dev](https://data-star.dev) and check out the [getting started guide](https://data-star.dev/guide/getting_started).
Every AI tool you've wired up by hand (the Slack integration, the database lookup, the "let the model read our docs" hack) is a one-off. You wrote the glue, you own the glue, and the next model or the next client can't use any of it. The Model Context Protocol is the fix: one open standard for how an AI app talks to your tools, your data, and your prompts, so you build the integration once and every MCP-aware client (Claude Code, Claude Desktop, Cursor, and a growing list) can use it. This is the guide I'd hand a competent developer who keeps hearing "MCP" and wants to actually build one instead of nodding along. We start from the problem it solves, get the mental model straight (hosts, clients, servers, and the three things a server exposes (tools, resources, prompts)) then build a real server from an empty folder: a tool the model can call, a resource it can read, a prompt it can reuse. We test it with the Inspector, wire it into Claude and Cursor, then take it remote over Streamable HTTP and talk honestly about the security boundary you're now responsible for. By the end you'll understand exactly what's happening when a model "uses a tool," and you'll have shipped a server you can point any MCP client at. _This is a living document and will be updated as the protocol and SDKs evolve._