Why this blog exists, and who it is actually for
Field notes from a solo founder shipping six production sites in three sectors. What I write here, what I do not, and why it might be useful to a few of you.
When I started this blog in January 2026, I described a portfolio of six production sites: EdTech in three markets, a retirement-advisory SaaS, a tutoring marketplace, and a small AI tutoring practice. The portfolio has grown since then; the home page presents my current work. Same person ships every release, answers every support email, and signs every invoice.
That changes how I think about software. Most of what I read about engineering, product, or growth assumes a team. A standup, a PM, a designer who sketches the flows before anyone writes code. The reality of solo work is different: you carry every layer, every day, and the only honest review is whether the metric moved.
This blog is where I write down what I actually learned shipping that way. Not what I read in a thread on X. Not the playbook I would teach if I were running a YC office hours. The patterns that survived two years of being wrong in production.
What I will write about
A few recurring topics, all from the workshop, none from a whiteboard.
Shipping fast as one person
Stack choices that pay off when you have no team to absorb the cost of a bad call. Why I run my own infrastructure on Proxmox instead of paying Vercel five times. How I keep deploys predictable across the portfolio.
Building with LLMs in production
What goes wrong when a single misbehaving prompt costs real money or burns a real customer. Retrieval pipelines that work without LangChain. Cost containment when you cannot afford to leak tokens.
Pedagogy as a product surface
Lessons borrowed from teaching chess and AI tools to professionals, applied to onboarding, support copy, and product education. The best UI improvements I shipped came from coaching, not from design heuristics.
Honest scoreboards
What works and what does not, with numbers. Roughly half of what I try fails. I write about the failed half too because that is the half nobody else publishes.
What I will not write about
No hot takes on AGI. No 10-step playbooks. No newsletter funnel at the bottom of every page. If a piece is not useful when read in isolation, it does not get published.
Who this is for
Two people. Other solo founders or small operators who are tired of advice written for someone else's stage. And smart juniors trying to read the actual shape of the work before they pick a path. If neither describes you, that is fine, but I will not pretend otherwise.
What is next
Start with the workshop notes for the published articles, or subscribe to the Atom feed. The next pieces will connect infrastructure decisions to the products and teaching work they support.