For twelve years, I've been pushing code while quietly thinking, "I wish someone could look at this."
I started building iPhone apps as a solo developer in 2014. In all those twelve years, I have never once had my code reviewed by another person. I've worked in teams here and there, but the apps that were truly mine — the ones that put food on the table — were always shipped on my judgment alone.
If you build solo, this might sound familiar. You push because the thing works. Six months later, you read your own code and squint at a decision you don't remember making, with no one around to tell you it's wrong. The same habits compound, year after year, and no one is around to point them out.
A little over a year into using Claude in earnest, I think I'm finally experiencing what it means to have a code-reviewing partner. This post is for anyone who's about to start building solo, or who's been doing it alone for years and didn't realize how much that silence was costing them.
The quiet problem of having no one to show your code to
The greatest freedom in solo development is shipping anything you want without asking permission. The greatest weakness is shipping anything you want without anyone questioning you.
My apps have crossed several million downloads in total, but even at that scale, the number of times I've received specific, technical feedback on my code is essentially zero. I've had users tweet "your app crashes," but I've never had anyone tell me, "this implementation is fragile because of X."
This kind of isolation doesn't dampen the joy of building. What it does is more subtle: your style slowly becomes the only correct answer in your head. By the time you notice, the same patterns are baked into the entire codebase, and untangling them feels like rewriting the whole thing.
The first week of asking Claude to review my code
I was skeptical at first. I didn't believe an AI could give me anything beyond surface-level suggestions. As a test, I pasted in a SwiftUI view I had just written and asked, "anything you'd flag here?"
What came back was more specific than I expected.
// A simplified version of what I had written
struct WallpaperGrid: View {
@State var wallpapers: [Wallpaper] = []
var body: some View {
ScrollView {
LazyVGrid(columns: [GridItem(.flexible()), GridItem(.flexible())]) {
ForEach(wallpapers, id: \.id) { wp in
WallpaperCell(wallpaper: wp)
.onTapGesture {
// navigate to detail
}
}
}
}
.onAppear {
wallpapers = WallpaperLoader.loadAll()
}
}
}Claude pointed out that running heavy synchronous work in onAppear would stutter the first scroll, and suggested wrapping it in Task while making sure the @State update happened on the main actor. It then offered to suggest caching strategies if I'd share what WallpaperLoader.loadAll() was doing.
That sounded exactly like the senior engineer that lives in my head. The difference was that this one would say it back to me at 2am, in under five minutes.
How Claude differs from a human reviewer — and where they overlap
I've had human seniors review my code in the side projects I've worked on inside teams. Claude's reviewing is similar but not identical. Here's how I think about the difference now:
- What Claude is good at: general performance principles, memory hygiene, missed error handling, naming inconsistency, missing test cases. These come from having absorbed enormous amounts of code, and the textbook-correct version of feedback is delivered reliably
- What Claude is weaker at: judgments that depend on product context — "this app's users behave like X, so stability matters more than speed here." Without that context, you get the generic answer
- What human reviewers are uniquely good at: judgments rooted in the team's history. "We got burned by this exact pattern last year, so write it this way" — that kind of tribal knowledge
- What both share: when you ask the right questions, both will surface options you didn't consider. The point of a review, I'm realizing, is borrowing someone else's perspective
These days I treat Claude the way I would treat a careful human reviewer: I give it context. "This app's users skew older, and many of them are on patchy mobile networks in rural areas." With that preamble, the suggestions get noticeably sharper.
The habits I couldn't see for 12 years
After several months of treating Claude as a reviewer, three patterns of mine became impossible to ignore.
The first was swallowing exceptions inside try-catch blocks. In solo development, "just make it stop crashing" is a tempting shortcut, but over time it turns into a graveyard of silent failures. Claude kept asking, "is it actually safe to swallow this exception here?" and after the third or fourth time, I started to understand the question wasn't rhetorical.
The second was tightly coupling UI with state. My SwiftUI views were stuffed with @State properties that should have lived elsewhere. "This state is reusable if you lift it out of the view" — the same suggestion, in different words, kept showing up. I had been calling that "good enough" for years.
The third was skipping comments. I had told myself, "I'm the only reader, so why bother?" Then I'd hand a file to Claude six months later and watch it struggle to interpret my own past intent. These days I aim for "enough comments that future-me three months from now can follow the logic," and that's been enough to ease most of the friction.
None of these were called out by anyone in twelve years. If they had been, maybe I'd have fixed them sooner. But "maybe" doesn't help. Catching them now is the only starting point I have for the next twelve years.
What I'd tell someone starting solo development today
If you're reading this and you're about to start building on your own, here's the one thing I'd offer.
Before you ask Claude to write code for you, get into the habit of asking it to read your code. Claude as a writing partner is fantastic. Claude as a reading partner is, in my opinion, where the real shift happens. Writing speed varies between people, but the frequency at which a solo developer can have someone look at their code has, until now, been close to zero unless they joined a team. Claude moves that floor.
A simple first step: take one file in your usual language, paste it into a conversation, and ask, "anything worth flagging here?" If even one of the suggestions makes you go, "huh, fair point," you now have a reviewing partner. That changes more than it sounds.
For deeper grounding, The Pragmatic Programmer (David Thomas, Andrew Hunt) is still one of the best books I know on cultivating the habits that solo developers, especially, struggle to maintain. Reading it alongside an active Claude conversation about your own code is a fast way to bridge book knowledge into practice.
I expect to keep building alone for years to come. But "alone" doesn't mean what it did twelve years ago. Solo development with a reviewing partner is a different practice from solo development without one. If you've been quietly building by yourself, paste a file into a conversation tonight. You might notice the silence get a little quieter.