There are days lately when I look around my home office, with four screens glowing, three products in various stages of becoming, and several conversations going with AI models, and realize that I appear to be running a very small software company whose employees happen to live inside browser windows.
I love it.
I have been building systems with AI for a while now, so I am well past the phase of being amazed that a model can write code. I can reason through architecture with a model, debug unfamiliar code, explore a new framework, evaluate implementation options, write tests, interrogate a product decision, and move across technologies much more fluidly with AI intelligence beside me. I can have an agentic team working on one product while I move to another, then come back and review what it did and iterate.
The important difference is not simply that I can code faster. It is that I can operate across more of the product. I can move from an idea to the user experience to architecture to implementation to testing and back again. That has expanded the scope of what I am willing to attempt on my own, and every time I attempt something, I learn something that makes the next attempt better.
A Different Kind of Experiment
For much of my career as an independent frontend web developer, technical knowledge created some fairly obvious boundaries around a project. I became a jack-of-all-trades kind of builder because projects rarely stayed inside the tidy boundaries described in the original scope. There were themes and plugins, hosting setups, integrations, databases, performance optimizations, and client requirements.
I became comfortable figuring things out. Given enough searching, testing, documentation, and tenacity, I could usually get to the other side of a technical problem. Of course, “given enough time” could occasionally mean losing two days to an error before discovering that the problem was microscopic, by which point the top of my browser had accumulated enough tabs to look like decorative fringe.
AI has dramatically shortened those detours, which means I get to spend more of my time on a different question: which work actually needs me, and which work only needs my judgment at the end of it? Everything I have built in the last year has been, in some sense, an attempt to answer that.
More Darts at the Board
Most of my current products have started with the observation that something in my life could work better.
My daughter was preparing for college, and I wanted a better way to explore the relationship between degree programs, careers, and possible salary outcomes, so I built Degree Pathways.
When I wanted to better understand the variables involved in investing and saving for retirement, I built Retirement and Investment Scenario Labs. I made it for myself and my family, with the hope that my kids might actually use it too, which is its own particularly demanding form of product-market validation.
Now we are updating our house, which has introduced paint, flooring, rooms, materials, budgets, and a ridiculous number of interconnected decisions into our lives. Naturally, I am building something for that too. If it turns out to be useful, I will release it.
The products are different, but the pattern is consistent. I start with a problem I understand because I am living it, build something I want to use, and discover what I got right and wrong by using it.
AI lets me move through that loop much faster, which means I get more darts at the board. Some of them land. One of them did not.
That does not bother me as much as it once would have, because the individual product is no longer the only thing I get from the experiment. Every attempt leaves building material behind, and I carry that into the next build. The dart may miss, but I still learn something about throwing.
Building the Builder
I do not want to keep relearning the same lessons inside every new project, so I transfer what works into infrastructure.
Now, when I begin something new, I type new-project into the terminal. That command clones a product template I have built for myself, complete with prompts, workflows, development structures, and scaffolding designed to take me and the AI agents through the product build cycle. I have an agentic development team with eight agents, including an orchestrator, and another team focused on product testing.
Compounding is not new to software. Stylesheets became design systems. Repeated code became functions, then libraries, then frameworks. We have always packaged what worked so the next project did not have to start from scratch. AI development is following the same instinct with different materials: a useful prompt becomes a prompt library, a reliable workflow becomes an agent, and agents become teams with orchestration, testing, memory, and guardrails layered around them.
So I keep asking myself a simple question. If I solve this today, what can I preserve so I do not have to solve it from scratch tomorrow?
Getting there is not tidy. One of the easiest mistakes in AI development is automating a process before figuring out whether the process deserves to exist at all, or building a web of processes that are not worth the time to maintain. Pruning matters as much as building. I try to note what I actually reach for in every build, and what I keep stepping over.
This is my jam, because if you have ever run a household, you learn to love a good system. Put the coffee cups where the coffee cups go. Take your laundry back to your room. Hang it up. Do not leave socks on the floor because the dogs will eat them, require surgery, and suddenly we are raiding the college fund. A good system prevents problems, makes collaboration easier, and saves everyone time and money. Apparently, I have been thinking like a systems engineer for years.
Four Screens and Several AI Colleagues
It seems that with all this AI efficiency, I am actually spending more time in front of my four computer screens.
On any given day, I may have three projects moving across four screens while carrying on separate conversations with multiple AI models. One is debugging something, another is researching an approach, another is testing a product, and I am moving among them, reviewing, redirecting, making decisions. It feels a little like air traffic control, except that the part that cannot be delegated is taste.
That way of working has changed what it means to me to be a solo builder. I have spent much of my career working independently, so having capable collaborators available whenever I reach the edge of what I know feels extraordinary. It has also made me more deliberate about making time for actual humans, who remain, on the whole, wonderful. And I already talk through ideas with a model while I am out walking, which makes me suspect that a fair amount of this work is going to escape the screen entirely before long.
Which brings me back to the question I am actually working on, underneath all the products. What am I building today, and how will it change what I am able to build tomorrow?
I do not think I will ever be finished answering it. That is more or less the appeal.