The idea came to me as I sat, exhausted, on my parents’ couch, unable to summon the energy to get up and go to bed.
When my family is together, once the kids are down after a typically full Sawczuk Family Day of Fun, the adults muster whatever physical and mental energy they have left and gather around the TV. For a while barely anyone speaks or moves — some of us need that time to decompress from bathtime and bedtime, and the rest of us understand that. But eventually we rally and someone uses their phone to AirPlay whatever photos they took that day to the screen. We go through them slowly, laughing at silly faces or remembering the moments the pictures were taken, then the next person who has pictures takes over, and so on.
During one of these sessions, I had the idea to find a photo on my phone from a long time ago, zoom all the way in on something in the background, and see how far I had to zoom out for my family to guess what it was. This was pretty well received, and for a while we took turns taking control of the TV and dramatically revealing our photo.
As fun as this little game was, it was a little clunky to execute. We were only using AirPlay, so anyone who didn’t have an iPhone was out. (Sorry, Ciocia.) You had to be zoomed in and ready to go as soon as you started AirPlay, otherwise you gave the game away too early. And just one finger spasm risked swiping to a new picture or someone’s text message saying, “I’m exhausted, why can’t we just go to bed.”
I had the idea that this could be an app. Everyone would upload photos from their own phones, and one person would drive the display without knowing what was coming. Maybe I could set something up to automatically pick an “interesting” feature of the photo to focus on, so even the uploader could be surprised. Ideally, I dreamed, it’d come with a native iOS app so the AirPlay experience was clean and not just a mirrored browser screen.
But I’ll be honest: I originally had this idea a few years ago, and it stalled almost as soon as I conceived it. My time to work on side projects is limited as it is, and I don’t know anything about writing even basic iOS apps, much less something with niche features like a custom AirPlay experience. It was a fun idea, I thought to myself at the time, but unless it was my full-time job for at least several months, there’s no way I’d ship anything I’d be proud of.
Unless you’ve been living under a rock for the last few years, you’ve probably heard about AI and how it’s coming for your job taking over our lives threatening our very existence having a moment. Here’s the spoiler: that idea I had, I managed to build it and ship it. You can check it out at farsighted.app, or download it from the App Store. I built it in bits and pieces, over nights and weekends, on my computer and on my phone. I built it when I had some time to kill on a weekend day, or after a long day at work. I built it with the same AI models and tools that made me question if I’d have a job this time next year.
While AI wrote just about every line of Farsighted, designed two logos and even walked me through the notoriously challenging App Store review process, it’s still my app, and I used almost every ounce of my experience and expertise to build it. Even more importantly: it was fun. What follows is the story of how I used AI to turn an idea I had while staving off bedtime into a real, shipped app.
Farsighted started its life as PhotoGuess. It was one of those evenings where I had a problem-solving itch to scratch and decided to see how far Claude could take it. The original idea was that guests would upload photos directly to a shared Google Photos album, then the host would hit start, 20 or so random photos would be picked and we’d be off. There was no database, no shared state, just a thin backend-for-frontend layer that handled API calls — most of the logic lived on the client.
I gave Claude (Sonnet 4.6) a short prompt which it expanded into a full spec, and we went back and forth about that for a bit before it confidently started building. The whole process took about an hour, and by the end of it I had something that worked but that I knew was dead on arrival. Google had locked down its Photos API so third-party apps could no longer read shared albums.
If I had spent a weekend building this, the disappointment of that dead end might have killed my enthusiasm for the whole idea. But at this point I was only an hour in, and before I even made this first commit I jotted down some notes for a v2 of PhotoGuess, with a plan to move to a proper backend with a database, abandoning the Google Photos dependency and just using simple file uploads. (The first commit specified that v2 should be a SvelteKit backend; I quickly followed that up with a second commit which pivoted the plan to Go.)
A few days later I had some more time to work and I implemented a basic version of what exists today: hosts could create a room and drive the reveal, guests could join a room and add photos. Anchors (the zoomed in points on the photos where the game started) were chosen randomly (and still on the client side), so the results were mixed. The reveal was entirely CSS, meaning that the backend shipped the full photo down to the client and the browser was responsible for cropping it before the users saw the full photo — by accident or on purpose, users were able to see the revealed photo early. And the app was still named PhotoGuess and looked about as fun as a corporate intranet.
But by this point, I knew I had something that could work. So I wrote out a roadmap with three main objectives, in summary: 1) rename and rebrand the app, 2) make sure uploading properly tagged photos is as seamless as possible, and 3) use AI to pick an interesting anchor for each uploaded photo.
I took care of the name, first. I used Claude to help me brainstorm some names, crosschecking against domain registrars. Some early contenders: “Aperture”, “Focal”, “Bokeh”, “Grain”, “Candid”, “Develop”. I learned that Claude had (and still has) a terrible sense of what domains might be available (pro tip, Claude: whatever you’re thinking, it’s probably taken). “Farsighted” came from a suggestion of “Farsight,” in what would become a pattern with how I tend to work with Claude while brainstorming: I use Claude to get me close but the final idea usually comes from me.
Part of my concern with uploading photos early on was that I wasn’t getting the proper EXIF metadata from the photos that were being uploaded. EXIF metadata is data that’s attached to photos by your phone or camera as you take them, so your photos app can track what camera took the picture, where you were, when it was taken, etc. Without it, the reveal couldn’t show where and when the photo was taken — which is the whole answer to the game, so it’s kind of a bummer if you don’t see it. I spent a few cycles iterating on improving this process, eventually landing on a solution where the client grabs that data and supplies it directly to the backend, rather than hoping that data makes it to the backend and letting the backend parse it out. Claude made that process take less time, but it was me specifying what I wanted and why that made it clear what Claude’s objective was.
The easiest of those three items was the AI-powered anchors. I went through a few iterations with different prompts and system instructions before landing on something that was good enough and moving on. Again, this process would have taken days if I had to do it myself. With Claude, it was done — or, at least, done enough — in one evening.
Along the way I also made a couple decisions that made my life easier going forward. As I almost always do with my projects, I set up automatic CI/CD so deploys became automatic and uneventful. I had Claude write an OpenAPI spec that I published where my frontend code could see it. I wrote good CLAUDE.md instructions that took away Claude’s opportunities to take cheap shortcuts.
But at this point, I hadn’t yet dared to dream about what I think is Farsighted’s killer app: the iOS app, with a custom AirPlay experience.
I’d never built an iOS app before this. I’d never had a real need, and opting in to building an iOS app means buying a Developer Program license and learning the App Review process at a minimum. It also includes learning a whole new tech stack if I’d wanted to use the iOS APIs that make building an app worth it over a web app. Because of the AirPlay dependency, this was the first time I had a real need. But even with that use case, until recently, the $99 fee and the learning curve probably would have scared me off from attempting it.
One night in June I started a repository, fired up Xcode and prompted Claude with some loose requirements and the idea of seeing how far I could get. As it turns out, Claude is just as adept at writing iOS apps as it is web apps. Here’s what it looked like after the first commit:
Candidly, I didn’t expect Claude to get this done on the first try. I expected frustration and that I’d end up giving up. Instead, Claude surprised me by not only getting it done but making it look relatively easy.
One way I brought my own expertise to the iOS project early on was setting up automatic CI/CD and a TestFlight pipeline. TestFlight is Apple’s way of providing beta builds to internal and external testers, and when you’re ready to ship an app to the App Store, you can simply select a build from TestFlight and promote it. Manually uploading a build is a lot of steps: you have to set the right scheme in Xcode, you have to make sure it’s signed properly, make sure you have the right version numbers, etc.
Instead, I knew that I wanted something more automatic, something I could do quickly at the end of a long night before I signed off for the day. So I spent some time telling Claude exactly what I wanted: run tests on PRs and commits to main; build, sign and upload to TestFlight on tagged releases. I further specified that I wanted marketing version numbers to come from the tagged release and the build number to be derived from the number of commits to main. I also asked Claude to specify what configuration or secrets I’d need to actually wire all this up properly, and to list those out in the PR so I could track them down. This worked really well and I’ve translated this approach to my other iOS projects.
Around this time (June 2026), Anthropic released some improvements to Claude Design. Claude Design — apart from burning through tokens like there was a bounty — promised to take your logos, brand assets, etc. and craft a coherent design system that you could then use on your apps, websites, slide decks, etc.
I didn’t have a logo or any brand assets, but I decided to give it a try anyway. Claude asked for a design brief, so I wrote what I knew at the time. (If I knew that this line was going to be immortalized in the design system I might have spent more time on it.)
Farsighted: a fun party game where players look at a cropped and zoomed-in photo and try to guess where it was taken and when. Fun, colorful and exciting.
Claude Design doesn’t like to design logos from scratch, and it told me so a few times — I had to remind it that I’m an engineer and not a logo designer and that anything it came up with would be better than what I could do. Here’s what it came up with:
Like the naming process, this logo wasn’t Claude’s first suggestion, and when we did get to something that resembled this in the process I had to steer it towards this final form. I was pleased with not only the logo, but the design system around it, and quickly worked to land it in the web and iOS apps. The web app was applied almost verbatim and looked great after the first commit. The iOS app took a few tries. Here’s the first version with the design system:
It took a little while for Claude to fix the double borders and make them shadows like they were supposed to be. It took even more coaxing to take that design language to the external display. And troubleshooting the look and feel on the external display proved difficult because the only way to reliably test the external display was to build the app to my own device and for me to actually fire up an external display.
The part of the process I was looking forward to least was the App Store Review process. Part of my dread was all the horror stories I’ve heard about people not being able to get their app through review. But the other part of it was simply “marketing fatigue”: that feeling you get when you exhaust all your creativity writing something or building something, only to finish and then have to summon just a little more creativity to write a post or email talking about what you made.
But like a lot of this project, when it felt like I was about to hit a wall, I had the thought to see what Claude could do to make this part easier. So I wrote a prompt asking Claude to write a release checklist: everything I needed to do to get the app ready for review. Once again, Claude delivered: not only a release checklist, but the values to provide to App Store Connect, including the description, how to answer the privacy questionnaire and app review notes for the reviewer. I even had Claude draft a privacy policy and a support page. All that was left for me was to gather some screenshots (a process that I have since automated).
The App Review process went smoothly, and on August 24th I released Farsighted on the App Store. A native app, built in my free time, was something I could only dream about just a few months ago.
Since I initially released Farsighted on the App Store, I’ve continued to add features and enhancements here and there. A few highlights:
-
App Attest. App Attest is a security feature that allows APIs to verify that requests are coming from a genuine copy of your app. Since the API uses AI and doesn’t require authentication, I was worried about runaway AI costs and wanted a way to limit that if I needed to.
-
Room options. Hosts can set a theme and set a maximum number of guests and photos per guest.
-
Panning and zooming on the final reveal. Often the funniest moments come from spotting someone’s crazy face or something in the background everyone missed the first time. Pans and zooms on the revealed photo (and seeing them translated on the AirPlay display) make those moments easier to catch.
-
A refreshed logo and design system. I found a Claude skill that reviews and creates logos, and after working with it for a while I was able to get a new logo that I liked even better than the first one:
Next, I want to redo the pricing model so that the app is free to download and comes with a handful of games for free, then you pay to host a game (less than $1 per game). I also want to explore adding a real way for guests to enter their guesses, rather than it being a totally offline experience.
Before you ask: I haven’t entirely stopped worrying about AI. The same tool I used to build Farsighted is the one that routinely sends me into existential crises at work and makes me wonder what my job looks like in a year.
But one of the dirty little secrets of software engineering is that most of what we build day-to-day is a predesigned Lego set, not a box of loose bricks. Most of Farsighted is that kind of set — a Postgres database, a REST API, an S3 integration for uploads, a TestFlight pipeline. What AI changed for me is how quickly I got through those “standard” parts to get to the parts that were new and interesting to me: the AirPlay display, the AI-driven anchors, and the overall presentation.
A few weeks ago my family and I were together and we got to play a few rounds of Farsighted. They all took their time picking some of their favorite photos from their phones, and we had a great time reminiscing about them. Some of those photos are iconic in our family and we’ve all seen them hundreds of times. But Farsighted helped us to enjoy them again like they were brand new.
It was almost exactly what I pictured on my parents’ couch. And I’m glad I built it.
Thanks to Sara Sawczuk for reading a draft of this post.