The Agentic Solopreneur

The Agentic Solopreneur

Summary

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.

Loading The Ceiling Moved…
Loading One Person Plus a Fleet…
Loading How I Got Here…
Loading Choosing What to Build…
Loading Your Operating Layer…
Loading Support Without Headcount…
Loading Content and Marketing at Throughput…
Loading Selling as One Person…
Loading What You Don't Delegate…
Loading Guardrails That Hold…
Loading Pricing When Delivery Is Nearly Free…
Loading Launching…
Loading How This Fails…
Loading What I Would Do Now…
Loading Toolkit: The Context Layer…
Loading Toolkit: The Delegation Line…
Loading Toolkit: The First 90 Days…
Loading About Roger…

Do you like my content?

Sponsor Me On Github

Keep reading

GTM Engineering with Agents: A Field Guide to Automating the Funnel

GTM Engineering with Agents: A Field Guide to Automating the Funnel

Every go-to-market team is really running a handful of pipelines. Leads come in, get cleaned up, get scored, get worked, and either turn into revenue or quietly rot. Most of that work is mechanical, and most of it gets done by hand or by a tangle of point-to-point integrations that break the moment a vendor changes an endpoint. This guide takes the agentic approach the rest of the series is built on and points it straight at the funnel. The idea is simple: wrap every source you care about (your CRM, your enrichment providers, your email, your product analytics) as an MCP tool, then let small agents orchestrate the motions on top of them. Capture, enrichment, scoring, outbound, nurture, hygiene, forecasting, churn signals. One tool surface, many agents, each running on a schedule. It's hands-on. We build each motion as a small agent loop over MCP tools, wire them together with a cron, and put guardrails around the parts that can email a customer or overwrite a record. By the end you'll have a mental model for GTM as a system of agents, plus enough concrete patterns to start replacing the manual busywork on your own stack. It pairs with [MCP from Scratch](/guides/mcp-from-scratch) for the protocol and [Running the Fleet](/guides/running-the-fleet) for orchestration. This one is about pointing all of that at pipeline. _This is a living document and will be updated as the tools and patterns evolve._

Read guide
The 70/30 Engineer

The 70/30 Engineer

The machine does about 70% of the typing now. That part is real, and it's not going back in the box. But the work that's left (guiding the agent, verifying what it produces, and owning the result) is the other 30%, and it turns out that 30% is the entire job. This is a field guide to working that way on purpose: a real, adoptable workflow for coding with agents, built on the AC/DC loop (Guide, Generate, Verify, Solve), grounded in what a year of agentic development actually taught the industry, the wins, the data, and the failure modes nobody likes to talk about. It's for the engineer who wants to be faster without shipping 1.7x more bugs to prove it.

Read guide