What a Year of Shipping With AI Actually Changes
A year ago I shipped ClawCost and wrote about building for niches. Since then I've shipped half a dozen more things. Here's what's actually different — and what isn't.
A year ago I was writing posts about building ClawCost in a week and finding software gaps in underserved markets. Since then I've shipped ClawHQ, Archalist, a family dashboard called Kith, a Chrome extension for web clipping, and a handful of tools that never got names because they solved a problem once and never needed to again.
I've also spent more time than I want to admit on things that went nowhere.
That's the honest version. Here's what changed.
Speed to working software is real
This is the obvious one, so I'll get it out of the way fast: the time from "I want to build X" to "X is running and doing something useful" has collapsed. Not 10% faster. An order of magnitude faster in many cases.
A year ago, ClawCost took a week. Archalist took a week. Things that would have taken me three months working alone now take days. That's not because I got better at writing code — it's because I spend almost no time writing boilerplate, fighting unfamiliar APIs, or debugging syntax errors. The implementation layer got dramatically cheaper.
This is real and it matters. But it's not the interesting thing.
The bottleneck shifted
Here's what I got wrong a year ago: I thought the constraint was coding speed.
It isn't. The constraint is clarity of thought. It always was. I just couldn't see it clearly because so much time was going into implementation that the thinking felt like it was moving fast too.
When implementation becomes cheap, the cost of unclear thinking becomes obvious immediately. If I can't describe exactly what I want to build, the AI gives me something technically correct and directionally wrong. If I don't know what problem I'm actually solving, I ship a solution to a different problem very fast.
The best sessions I have are the ones where I've done the thinking first — where I know what the outcome should look like, what the constraints are, what I'm not building. The AI is a remarkably fast implementation partner. It is not a substitute for knowing what to build.
That's the shift. It's a good one. It forced me to get better at the part that actually matters.
What I built and what it taught me
ClawHQ is an agent control plane — a dashboard for managing and monitoring AI agents across projects. Building it taught me that managing AI agents is a completely different problem from building them, and that the tooling gap there is real.
Archalist is a curated resource directory for architects and designers. I built it in a week, and the interesting part wasn't the speed — it was how much the quality of the initial design thinking determined what the product became. The weeks I spent thinking about what a useful resource directory actually looks like paid off more than the week of building.
Kith is a family dashboard running on a wall-mounted TV in our house. It does events, chores, weather, grocery lists, and a dozen other small things. I built it because I couldn't find anything that worked the way I wanted, which is the same reason I built every other thing I've shipped. Building software you actually live with teaches you things you can't learn from user interviews.
Each of those projects confirmed the same thing: I can build faster than I can decide. And deciding is still fully human.
What AI still can't do
It can't tell you what to build. It can't tell you whether the thing you're building is worth building. It can't do the market research that determines whether a pain point is real or imagined. It can't read a conversation with a potential customer and decide whether you're hearing a real problem or a polite lie.
It also can't hold the vision of the product across a long build. I've started using explicit planning documents — writing out what the product is, what it's not, what the key design decisions are — specifically because the AI will drift toward safe, generic interpretations if you're not constantly correcting the heading. That's not a criticism. It's just a property of the system that requires compensation.
The builders who are going to win at this aren't the ones who can code fastest. They're the ones who know what to build. That was always true. AI just made it more true.
The year ahead
I have things in the pipeline that would have felt impossible to build two years ago — not because of technical complexity, but because the time investment was too high. Now the investment is mostly thinking time, and I've gotten better at that.
The limiting factor isn't capability anymore. It's prioritization and focus. Which problems are worth solving. Which markets are worth entering. Which things I should build versus leave for someone else.
That's a better problem to have. It took me a year to see it clearly.