Nobody typed a single line of code for this iOS app, and it’s already live on the App Store. The developer behind it, who posts on Reddit as u/jmathai, built the whole thing through Claude Code, one AI-generated feature at a time. “Sojourn: Topical Bible Study” streams AI chat in real time. Every scripture citation gets swapped for verified text from a bundled database, so nothing gets hallucinated.
Tap any verse and you can explore the whole surrounding chapter without leaving the chat. That’s the kind of detail that makes people trust the citations instead of double-checking them elsewhere. Forty-five features like this shipped in a matter of weeks, each one closing a GitHub issue overnight while he slept.
The backend runs in Python and calls the LLM through a “tool” built for scripture lookups. That way the model never has to get references right on its own. No chats or user identity get stored anywhere outside the app. Out of 49 GitHub issues opened, 45 are closed, which comes out to 45 shipped features in weeks, not months.
The twist
Here’s the part that actually matters: “one-shot” doesn’t mean he wrote one clever prompt and got lucky. It means the hard decisions got made before any coding agent touched a single line. Every feature starts as a “/spec,” a skill where he and Claude nail down the happy path and the failure modes first. Then they lock the architecture and the tests before any code exists. Only once that’s settled does he run “/gh-issue” on the ticket number and walk away.
Two examples show the leverage:
- The home screen widget: 2,466 lines of code, 27 files, one prompt, one pull request.
- Emailing yourself a conversation: 2,412 lines of code, 21 files, spanning the client, the backend, and an email provider, still one prompt.
Neither is a small feature. Neither is boilerplate, and both shipped in a single pass!
One commenter nailed why this works: the pipeline from spec to implementation is the real product here, not the prompt itself. Most people obsess over generating code and skip the step where the feature actually gets defined. That’s backwards, and it’s exactly where he spends most of his time.
So what’s actually the bottleneck? Not code generation. He still shapes each spec until the feature feels right, because more features per day isn’t automatically better. The four issues still sitting open aren’t blocked. He just hasn’t decided they’re worth building yet.
How to steal this workflow
- 📝 Build baseline context once. A “CLAUDE.md” file plus a handful of product docs define permanent constraints, like “never collect personally identifiable analytics.” Every future spec inherits these rules automatically.
- 🎨 Prototype the UX separately first. He co-designed the whole app in Claude Design before touching Xcode, then fed that interactive prototype back in as context. Claude Code understood the prototype well enough that the shipped app looks nearly identical to it.
- Run “/spec” on each feature. Work out the happy path, the failure modes, and the look and feel first. Then let the skill turn the finished conversation into a GitHub issue, complete with a testing plan.
- Cross-link related issues. If two unshipped features touch each other, reference them in both issues so the coding agent pulls in the right context automatically.
- 🌙 Run “/gh-issue [number]” and leave the room. He often kicks this off before bed and wakes up to an opened pull request.
- Automate anything you do twice. Scripts like “run.sh,” “deploy-to-device.sh,” and “release.sh” mean publishing never becomes a manual chore again.
Pro tips
- Keep global constraints, like privacy rules and tone, in the baseline context file instead of scattering them across specs. Write it once, every feature obeys it forever.
- Treat the interactive prototype as a spec, not a mockup. A coding agent reads a working prototype far more precisely than it reads a written description of one.
- Batch your releases. Not every closed issue needs to ship to the App Store immediately. Group features and release on your own schedule.
Worth saying: the developer has spent decades building software and launching startups before any of this. That experience is doing real work here too. Still, the mechanism itself doesn’t need decades of experience. Spec first, code second: any of us can copy that starting today.
Go peek at “Sojourn: Topical Bible Study” on the App Store and see the widget and the email feature in action. Then go write your first real spec before your next prompt. 🚀📖
Frequently Asked Questions
Q: Why is the spec/design phase the real bottleneck, not code generation?
Most developers assume AI code generation is the hard part. In reality, clear upfront specs matter more. With a detailed design (like the Claude Design work done before Sojourn), you give the LLM unambiguous parameters to work from. The code generation becomes almost mechanical. Skip the spec? You’ll spin on back-and-forth tweaks. Do the spec right? One-shot implementations become possible.
Q: How complex can a single prompt actually handle? Can it really span multiple systems?
Yes, Sojourn’s widget feature is 2k+ lines and connects WidgetKit plus App Groups, implemented in zero follow-ups. Widget and email features both hit 2k lines cleanly. The pattern seems to scale to multi-system iOS integrations, as long as your spec clearly defines the boundaries and dependencies upfront.
Q: How much time should I spend designing vs. letting AI implement?
The ratio is heavily front-loaded toward design. You’re spending days refining features and UX in tools like Claude Design, then handing off a complete spec. Implementation runs faster because the AI doesn’t need to guess. It’s the opposite of code-first workflows where iteration happens in implementation.
Sojourn for iOS Was 45 One-Shot Prompts
by u/jmathai in PromptEngineering