I built four iOS apps in the last month.
- Orbit, a personal CRM
- Visit Notes, an AI scribe
- Mosaic, an Apple Watch explorer
- Curator, a photo album app
They’re not masterpieces. They’re real enough to be useful, real enough to be a little embarrassing in places, and real enough to teach me (again) that software is mostly an endless series of small decisions.
I’m still slightly surprised that this is even possible right now.
Because I’m not an engineer. The last time I “coded” in any meaningful way was on an Apple II, in Logo, when my biggest problem was getting a turtle to draw something that looked vaguely like a square. Most of the latter part of my career has been product: customers, tradeoffs, roadmaps, strategy. I’ve worked closely with great engineers, and I’ve always respected the craft from the outside. But there’s been a membrane I rarely crossed. I could sketch the “why” and the “what.” The “how” belonged to someone else.
Over the last year, that membrane thinned.
Not in a heroic way. Not in a “watch me become a 10x developer” way. More like… the friction dropped enough that building stopped feeling like a special event. It started feeling like something you can just do. Like writing a doc. Like making a deck. Like opening Notes and thinking out loud—except the thinking turns into working software a lot faster than your brain is prepared for.
It reminds me a little of Ratatouille, not because I think everyone should be a chef, but because of the quieter message: great work doesn’t always come from the expected place, and sometimes the difference between “I have taste” and “I can make something” is simply being able to try.
I don’t think the progress shows up best in benchmark charts. I notice it in what I can do on a weekend.
From understanding to building
At the beginning of last year, I used ChatGPT the way most people do when they first realize it’s genuinely helpful: as a replacement for Google, especially for the kind of questions where you don’t want links so much as a clean explanation. Instead of hunting through tabs, I’d ask for a synthesis. Give me the landscape. Give me the vocabulary. Give me the tradeoffs. Help me form a point of view fast.
That alone was valuable. It made me quicker at getting oriented in unfamiliar territory. It turned “I have a vague question” into “I have a model I can reason with.” It also became an editor I could consult any time: tighten this paragraph, sharpen the opening, make this email less confusing, help me say the thing I mean without sounding like a robot.
Then the use changed almost without me noticing. The questions got bigger.
I started using Deep Research like a daily habit, the way you might check the news or skim a few Substacks. I’d pick a market or a category I didn’t understand well enough yet, and within the same day I’d have a structured report: the main players, how they position, what customers care about, what people pay for, where the weak spots are. The surprising part wasn’t only the speed. It was how it changed my willingness to explore.
When research is expensive, you ration it. You wait until you’re sure the question is worth asking. You pick one path, because five paths would be wasteful. When research becomes cheap, you can follow curiosity more honestly. You can test a hypothesis by trying to disprove it quickly. You can spin up a map, tear it down, and spin up a better one without feeling like you’re burning money or time. It’s not that you stop needing judgment; it’s that you get to apply judgment sooner.
That’s when ChatGPT stopped feeling like a search tool and started feeling like a thinking partner.
The prompts shifted. Less “what is this?” and more “how would this actually work?” Less “explain” and more “pressure-test.” I found myself asking questions I usually reserve for the messy middle of product work: what would break first, what assumptions are hiding in the plan, what would make this predictable, what should we measure if we want to know whether it’s working.
That’s a different relationship than “answer my question.” It’s closer to having a strong colleague available on demand—someone you can throw half-formed thoughts at and get back structure. Not truth from on high, but scaffolding you can climb and kick and revise.
Somewhere around the middle of the year, I also became more aware that “the model” isn’t one thing. The experience started to feel more like a set of gears you can shift depending on the task. Sometimes you want speed. Sometimes you want depth. Sometimes you want something to hold a lot of context without drifting. Sometimes you want a careful chain of reasoning. Sometimes you want a quick draft you can revise.
I didn’t get obsessed with model names so much as model behavior. Which is probably how it should be. The point isn’t the badge. The point is what becomes feasible.
When prototypes become products
And then I tripped into prototyping.
At first, prototyping wasn’t about shipping. It was about making ideas legible. I’ve spent enough time in meetings to know how abstract debates go: lots of opinions and nothing moves. A prototype changes the conversation. It doesn’t settle everything, but it moves the discussion from opinion to interaction. People stop arguing about what they imagine and start reacting to what they can touch.
The early prototypes were the kind you build to communicate—rough, imperfect, more like a sketch than a product. But even those taught me something important: planning and scoping hide a lot. You can’t fully anticipate how a feature will feel until you try to use it. You can’t predict where the awkwardness lives until you run into it. Prototypes are a form of research that happens to look like software.
Once that clicked, the next step was almost inevitable.
Because if you can prototype in a weekend, you can also… keep going. Add a little polish. Fix the obvious bugs. Make it usable for someone other than yourself. The line between “toy” and “real” isn’t as dramatic as it sounds. It’s a sequence of small decisions and a little stubbornness.
That’s how I ended up building those four apps in a month.
Not because I suddenly became technical. More because the AI tools let me stay in the language I’m fluent in—intent, behavior, user experience—and still make progress through the technical layers. I could talk my way through a build. I could ask for a plan, try it, hit an error, and iterate. I could learn simply by doing.
It was still hard in the way building is always hard. Just different.
When you actually build something, you start to appreciate the density of decisions hiding under every screen. Naming things. Handling edge cases. Deciding what happens when the network drops. Choosing what you won’t support. Getting the UI to feel obvious instead of clever. Making tradeoffs you didn’t know you were going to face. Software is a thousand tiny judgment calls stacked into something that feels simple on the surface.
And the act of building generates information you can’t get any other way. This is the part that surprised me most. I’ve always believed in moving fast, but building made it visceral: the feedback you get from a working thing is qualitatively different than the feedback you get from a plan. Shipping—even in small, private increments—turns uncertainty into data. It forces clarity. It exposes what matters.
That’s what the last year has felt like for me: the distance between “I have an idea” and “I can test this idea” has collapsed.
So when people ask what changed, I’m tempted to say something simple like “models got better.” But that’s not the lived experience. The lived experience is that the unit of value changed. It went from answers to outcomes.
Early on, the value was speed of understanding. Later, it was speed of synthesis. Then it became speed of reasoning through ambiguity. And lately it’s become speed of building: speed of turning intention into something you can use.
I’ve always believed that a small group of focused, passionate people can do amazing things. The last year makes me think we’re about to see more of that, not because everyone suddenly becomes a genius, but because the friction to create has dropped. When you can prototype cheaply, you explore more. When you can explore more, you find better ideas. When you can ship faster, you learn faster. It’s a compounding loop.
When building gets easier, judgment matters more
There’s a sobering side to this too. The bottleneck doesn’t disappear; it moves. When building gets easier, taste matters more. Judgment matters more. Knowing what not to build matters more. Understanding users deeply enough to build the right thing matters more.
But that’s also why this moment feels energizing as a product person. A lot of my career has been about translating intent into execution through teams, processes, and time. That will always matter. But now there’s a new option: sometimes you can translate intent into reality yourself, quickly, just to learn.
A year ago, I mostly used ChatGPT to understand the world faster.
Now I use it to make things that didn’t exist last week.
That’s a different kind of progress. It’s quieter than benchmarks. More personal. And, in the best way, a little absurd.
