Building an iPhone app without writing a line of code
I have a Computer Science degree. I started my career as a developer. Then I didn't write code professionally for more than twenty years.
Last year I worked through Harvard's CS50, which dusted off some old instincts and gave me a working knowledge of Python. But iOS development? Swift? React Native? Nothing. So when I decided to build SegmentPacer — an iPhone app for cyclists — I was starting from a long way back.
What follows is what actually happened, including the bits that surprised me.
The app
I wanted something non-trivial. Not a to-do list, not a weather widget. SegmentPacer integrates with Strava and helps cyclists pace themselves on segments — those named stretches of road that riders compete on for leaderboard times. The app uses physics models (cycling power equation, Newton-Raphson speed solver, terrain block segmentation) to work out the optimal way to ride a given segment based on your power profile, the gradient, and the segment's length.
For a non-developer, the combination of physics modelling, Strava OAuth and API integration, and a polished iOS UI made this a fairly meaty build. Which was the point.
How I worked
I fell into a pattern fairly quickly. Claude Chat became my product manager and analyst — a sounding board for ideas, a place to think out loud about architecture, edge cases, and trade-offs. Claude Code was the developer.
The flow was roughly:
Explore a feature or problem in Chat — what should it do, how should it behave, what are the edges?
Get Chat to write a precise prompt or spec for Claude Code.
Hand that to Claude Code, watch it build, then bring the result back to Chat.
Discuss what came back. Refine. Repeat.
I spent a lot of time shuttling information between the two. It felt a bit like being the only human in a meeting between a strategist and an engineer who couldn't talk to each other directly.
The shift to markdown files
The shuttling got tedious. Every new Chat session needed context — what the app was, what was built, what was broken, what was deferred. I was retyping the same things, and I was also blowing through tokens.
The fix was obvious in retrospect: markdown files in the repo. I started with hand-written ones produced from Chat — a SPEC_MVP1.md, then SPEC_MVP2.md, then SPEC_MVP3.md. Later, I got Claude Code to update a session handoff document at the end of each working session, summarising build status, deferred issues, and known tech debt.
This changed things. Instead of starting from scratch each time, I could point a fresh session at the current state document and pick up exactly where I'd left off. It cut my overhead noticeably and — I'm fairly sure — reduced token usage as well, because I wasn't re-explaining the same context every time.
If I were starting again, I'd build that habit from day one.
The cost
I started on Claude Pro. For a while it was fine. Then, as the project got bigger and the sessions got longer, I'd hit the rate limits after one or two changes and be told to wait several hours before continuing. Not great when you're in flow.
I tried API top-ups. They got me unblocked, but the meter was running at something like £10 an hour of active work. I've since moved to the Max plan and the limits have stopped getting in my way, which is what I'd recommend if you're planning anything sustained. Worth flagging honestly though: this is not a free way to build software, and the economics are something to think about before committing to a project of any real size.
I never looked at the code
This is the part I'm least sure about. From start to finish, I did not open a single source file to read it. Not once.
In one sense that was the experiment — how hands-off can a non-developer actually be? Could I direct a build using product thinking and natural language alone? The honest answer is: yes, I could, and I did, and the app works.
In another sense it's a slightly uncomfortable thing to admit. I have no idea whether the code is clean or a mess. I trusted Claude Code to flag tech debt (which it did — there's a list of known issues in my handover doc, including a client secret exposed client-side that I'm aware of and haven't addressed yet). But I never independently verified anything.
I wouldn't recommend this approach for production software you're shipping to paying customers. For a learning project where the goal is to see how far the model can take you, it was genuinely revealing.
What I learned
Three things worth saying.
The product manager / engineer split worked better than I expected. Treating the two Claude products as different team members with different jobs forced me to think more clearly about what I was actually asking for at each step.
Persistent state in markdown is the unlock. The single biggest efficiency gain wasn't a clever prompt — it was just keeping good notes in files the model could read.
Cost is real. Pro wasn't enough for a project of this size — Max has been, but it's worth going in with eyes open about what sustained AI-assisted development actually costs.
I'm now using SegmentPacer on my own rides. It's not in the App Store yet — there's tech debt to clear and the deferred issues from MVP3 to address — but it works, and I built it.
That still feels like a strange thing to type.
And yes — I got Claude to write this too. I did supply the ideas, the experience, and a fair bit of editorial direction. Seemed only fair.