Shipped 3 apps to App Store in a month. Self-taught, no CS degree. Built AI App Factory — native mobile apps with AI agents. Building in public.
Joined March 2022
- Tweets 1,624
- Following 684
- Followers 260
- Likes 378
Photos and videos
May 31
Before I ask a coding agent to fix an app, I want a reviewer agent to reject it first.
Not philosophically.
Literally:
read the code, list the top 5 reasons this build would fail review, map each one to a fix.
The fix prompt gets much better after that.Before I ask a coding agent to fix an app, I want a reviewer agent to reject it first.
Not philosophically.
Literally:
read the code, list the top 5 reasons this build would fail review, map each one to a fix.
The fix prompt gets much better after that.
2
1
396
May 24
I used to think the hard part of mobile apps was the code.
Then I shipped my own apps and hit the boring wall:
metadata, permissions, screenshots, review notes.
Localhost is a checkpoint.
The store is the finish line.I used to think the hard part of mobile apps was the code.
Then I shipped my own apps and hit the boring wall:
metadata, permissions, screenshots, review notes.
Localhost is a checkpoint.
The store is the finish line.
2
1
11
1,049
May 22
I used to think the last 20% of an app was polish. It was not. It was build profiles, permission copy, screenshots, review notes, backend URLs, and store metadata. AI made coding faster. It did not make finishing optional.I used to think the last 20% of an app was polish. It was not. It was build profiles, permission copy, screenshots, review notes, backend URLs, and store metadata. AI made coding faster. It did not make finishing optional.
1
6
734
May 17
I used to think a better starter template would fix app shipping. It didn't. The hard part was after the repo looked clean: PRD decisions, auth edge cases, deploys, screenshots, review notes. That's why I care more about systems now.
4
1
7
1,083
May 15
An app generator can get you to localhost.
Shipping starts after that:
metadata, permissions, screenshots, review notes, deploys.
That is the part most people skip until it hurts.
2
5
1,039
Boaz Hwang retweeted
May 14
Mitchell's post here reminded me of a similar conversation I had recently about how cheap it can be to port native mobile apps to React Native using coding agents... and then port them back again later if it turns out not to work out simonwillison.net/2026/May/1…
May 14
It isn't unexpected that the focus of the Bun Rust rewrite is on the anti-Zig side more than anything, since the internet loves to hate. What is unexpected and unfortunate is that leadership within Bun hasn't tried to steer the conversation away from that at all.
There are so many positive and interesting takeaways from this and I'm not really seeing any of them pushed as the primary message.
A positive thing that hasn't been talked about at all is how far Bun came thanks to Zig. And even if you dump it now, its meaningful for how good Zig was to even build a product to this point and impact by any metric. I would've loved to see anyone in leadership say this.
On the interesting side is how fungible programming languages are nowadays. Programming languages used to be LOCK IN, and they're increasingly not so. You think the Bun rewrite in Rust is good for Rust? Bun has shown they can be in probably any language they want in roughly a week or two. Rust is expendable. Its useful until its not then it can be thrown out. That's interesting!
There's been a lot of talk about memory safety and no doubt Rust provides more guarantees than Zig. But I'd love to see a better analysis of why Bun in particular suffered so much rather than take the language-blame path. How could engineering as a practice been more rigorous to prevent this? What were the largest sources of crashes other programs should watch out for? How does Rust prevent them? How could Zig theoretically prevent them? That's interesting.
I know the official blog post hasn't come out yet from Bun. But they're smart enough to know that that PR would stir up controversy the moment it opened, or they should've been. And plenty in the company have been tweeting and writing about it. Its somewhat telling to me in various dimensions what they chose to talk about first.
I tend to think I'm pretty good at corporate PR/comms (especially when it comes to developer audiences) and I think appealing to the negative is never the right long term strategy; it does work to get short term eyes though.
40
10
262
60,610
May 13
Most unfinished apps are not a coding skill problem.
The app runs locally. Then PRD, privacy text, screenshots, store review notes, backend deploys, and test accounts show up.
That's where people stop.
Shipping is its own loop.
1
648
May 12
AI made the typing part fast.
But the bottleneck moved.
Now it is PRD, auth edges, deploys, screenshots, review notes, and the boring store checklist.
Most apps do not die in the IDE.
They die between localhost and submission.
1
3
449
May 11
A coding agent is mostly an async sequence problem.
Tokens stream in.
Tool calls pause the stream.
UI still has to update before the turn is done.
The deeper I look at Claude Code, the more it feels like architecture chosen by one language feature.
3
346
May 10
I keep learning the same lesson with coding agents: the tool is the skeleton. The useful part is the workflow you write around it. If my process is not clear in plain text, the agent only makes the confusion faster.
3
6
294
May 8
Browser automation taught me a weird AI lesson:
More page data can make the agent worse.
If the job is "click Sign In," the whole DOM is noise. A tiny snapshot with the button name is enough.
2
1
3
487
May 7
AI makes the wrong direction cheaper too. If the problem is fuzzy, the agent does not slow you down; it just builds the fuzzy thing faster.
4
5
460
May 6
I used to think React was a web UI library. Reading Claude Code changed that. It is a way to keep stateful output honest while the renderer changes: DOM, native views, terminal text. Surface APIs age fast. The deeper shape travels.
1
1
445
May 5
AI made writing tests cheap, but it did not make safety cheap. I trust the boring bottom layer more now: typecheck, lint, build. The faster code appears, the more I want rules that catch mistakes before anything runs.
2
3
414
May 2
Coding feels like the finish line until you try to ship.
The first real release taught me the app was done only when certificates, screenshots, privacy forms, and review notes stopped blocking it.
Shipping is a workflow, not a build command.
1
1
9
585
May 1
Manual QA does not fail because people are lazy. It fails because humans naturally retest the happy path. The cases that break the app are boring: no network, double tap, empty input, expired session. That list needs to exist before code.
1
8
573
Apr 29
Most AI workflows do not fail because the model is weak. They fail because the workflow only lives in your head. Once the steps are written down, turning them into a skill is the easy part.
1
8
582
Apr 26
I used to treat depth and speed like a tradeoff.
Shipping apps with agents changed that.
AI speeds up execution, not direction. If your judgment is shallow, you just get to the wrong place faster.
5
547
Apr 13
I shipped 4 apps to the App Store in one month.
Solo. Self-taught. No CS degree.
Before that, I killed 7 projects. Same mistake every time — I built everything except the core feature.
Now I build the core feature first. Ship. Then iterate.
2
2
369