The Case for Software That Builds Itself
How We Build
Jesper Ellesson is a UX Designer at Fantasy. Over a weekend, he built a gym tracker for iOS using Claude Code and Xcode. He'd never opened Xcode before.
The problem
Designers spend their days building things people can look at but never touch. Static prototypes get clicked through in meetings. They cannot answer the question clients actually care about: how does this feel in use? Jesper wanted to close that gap himself, on his own time, with tools that were finally good enough to let a designer ship real software.
What made you actually do this?
“I saw colleagues around me building real things with AI tools, and I wanted to try it for myself. I’ve been hacking together websites since I was a teenager, but I always found the technical side too complicated and too long to learn properly. When I saw how quickly people were going from idea to working software, I realized I could finally start taking my own ideas into reality.
“I’ve always wanted to create an iOS app. And I realized there was nothing stopping me. So I found some time and got to work.
“As to why this particular project: it was a combination of FOMO, curiosity, and personal need. I’ve tried plenty of gym apps that do the same thing, but you always hit a paywall or there are just too many features I don’t need. I wanted something very simple and genuinely useful. When I go to the gym I just need my routine, my weights, and a timer. That’s basically it.”
The first hour in Xcode
“I went to YouTube and typed “Xcode + Claude” and found a great beginner’s video from a YouTuber named Alex Finn. That made the setup fairly easy.
“But I hit a wall when I tried to run the app on my phone for the first time. I was like, how do I see what Claude has made? I want to put it on my phone. How the hell do I put it on my phone? This seemingly obvious thing was not obvious at all. I had to troubleshoot with ChatGPT to figure out how to set my iPhone into Developer Mode and actually install the app on my device.
“That was the hardest part of the whole experience. The environment setup, every bit of it.”
The prompt
“The initial prompt went something like this:
"I want to build a simple iPhone app in Xcode that helps me at the gym. I need it to be able to create routines. I need to be able to add exercises within that routine. I need to be able to search from a library of common exercises to add to a routine. I need to be able to input what weight and how many reps I did for that exercise. I need to be able to see the weight and sets I did previously. I need to be able to reorder the exercises within the routine. I want to be able to start a routine, and when I start a routine I need a rest timer between each set. Once I’m finished with the routine I want a list view of all my previous routines I finished.
“A colleague recommended I use the Planner inside Claude Code. That was mega helpful. I sent it that long paragraph of features and some very light art direction, it asked me a few clarifying questions, I approved the plan, and in a ridiculously short amount of time I had a working app on my iPhone.”
Where it broke down
“Mostly it just worked. But as I tested the app I started to notice small bugs. When I tapped the input field to type the weight for an exercise, there was no way to dismiss the keyboard. I described the problem to Claude in plain language and it sorted it out immediately.
“The surprise was how conversational the debugging felt. I didn’t need to understand the code to explain what was wrong, and Claude understood the context because it had built the thing in the first place.”
The moment it shifted
"The moment I opened the app the second or third time after fixing some bugs, I realized it was going to work. I had discovered that I could just iterate and improve infinitely. At that point I couldn't go to sleep. I was up until 4am going back and forth, adding features and starting to see that I could create more of an experience: an intro splash screen, an animation after the workout was finished.
"That's when it stopped being an experiment."
What I'd do different
“I’d try React Native so it would work on Android as well. And I’d plan more. I’d really think through the features in a much more comprehensive way before building, rather than figuring it out as I went.
“That’s the part that felt most familiar to me, actually. Defining what the app should do, thinking through the user flows, understanding how someone would actually use this thing at the gym. That’s what I do every day as a designer. I just didn’t realize until this project that the same thinking could take me all the way to a working app.”
Jesper spent a weekend building an app he now uses at the gym every week. Claude Code handled the Swift. The hardest part of the whole experience was environment setup: developer mode, device provisioning, getting the build onto his phone.
Once that was sorted, the rest was the work he already does every day: defining features, thinking through flows, deciding what the experience should feel like in someone’s hand. The skill that carried the project was the one Jesper already had.
What to try this week
Install Claude Code and open the native IDE for whatever platform you actually use. Pick one flow from a recent prototype that has always felt thin in static form, the one you keep wishing you could hand a client with real interactions attached.
Rebuild it as working software over a weekend, scoped small enough to install on your own device by Sunday night.
Start with the Planner inside Claude Code, the way Jesper did, and write the feature list as one long paragraph before you touch the IDE. The planning is the design work, and the tools handle everything else.
What in your current design process stops at the artifact because the tooling couldn’t take it further?
If you had a working build of your next concept on your phone by Monday morning, how would that change the conversation with your client?
What would you build this weekend if you knew the hardest part was getting your phone into Developer Mode?