Designed, built and shipped to the App Store
Overview
Linguease is an iOS app that teaches you vocabulary at the moment you open Instagram. A word comes up before your feed does, and you type it to get through. That's more or less the whole product.
The thinking is simple enough. Language apps mostly die because you forget to open them. Nobody forgets to open Instagram ro TikTok. So rather than trying to build a new habit, the app sits inside one you've already got.
Although I have a broad understanding of code, I don’t write it myself. Claude writes it and decisions are all mine. That changes what the job is: when the code stops being the bottleneck, what's left is deciding - what to build, what to leave out, when it's done. Most of this page is those decisions. The app went live in April 2026.
Two decisions carried the build. Shipping native code I can't read without shipping something unsafe, and being able to tell whether any of it was working.
Product design
The problem
The idea came from living in Brazil. My Portuguese wasn't improving and my screen time wasn't going down, and after a while I noticed these were the same problem: the spare minutes the language needed were going to the scroll. Talk to other expats and you hear the same double guilt everywhere.
The starting question was narrow: I want to remember specific words, so what is the best way to put them in front of me?
Build · The method
Decision 01 · Shipping native code I can't read
The product only exists within the iOS framework: widgets, the Shortcuts intercept, native subscriptions etc. So the real question was never which framework. It was how someone who doesn't code ships native Swift without shipping something unsafe and unsecure.
The call
Learn Swift properly first: a year of evenings before anything ships, and the product dies as a course.
A no-code or web-wrapper builder: can't reach the surfaces this product lives on, meaning widgets, intercepts and native subscriptions.
Claude Code writes the Swift; I direct it, review every change on device, and own every design decision and its consequences.
In practice it works like the Design and Developer split I spent seven years inside, except I'm now on both sides of it. Describing turns out to be the skill: vague briefs produce vague code.
Security had to be designed, not checked at the end
Apps built this way fail in predictable ways, so I went and read about which ones. Secrets left in the client. Endpoints that trust whoever calls them. Input that reaches the database unvalidated. Data rules left open because closing them broke something during the build.
So security got written down first, as a spec: what the app is allowed to hold, what the server is allowed to accept, what has to be true before anything ships. Then I turned that spec into review passes Claude had to run against its own output.
The limit is obvious though. I can’t audit code I can’t read. So I researched and hired an iOS developer to review it properly, so the plan came from someone with real expertise rather than from my own reading of a checklist.
That’s the principle the whole build runs on. Human expertise is the slow, expensive input, so it goes where it changes the outcome: security review, and the design decisions. Everything else is direction.
A design system sized for the tool
I designed the app in Figma, and the temptation was to build a proper design system underneath it. I didn’t do that. Instead I built the smallest one that did three jobs: let me design quickly and beautifully, keep the file clean and scalable, and give Claude something consistent to read through the Figma MCP. Type, colour, spacing, a handful of components.
This app was built in the hours around a full-time job. A deeper system and a more considered visual identity were both available, and both would have cost weeks. What I wanted was something small enough to be fast and good enough that would result in something beautiful and consistent.
What it cost
I won't pretend the method is smooth. Builds went backwards and changes broke things that had been working. What that taught me was to move the thinking earlier. An ambiguous instruction doesn't stall the model, it decides for me and sounds equally sure either way, so anything I didn’t choose in the plan got chosen by accident.
App Store review was the honest test which that was approved after 8 days, and the live app hasn't crashed since.
Instrumentation · Systems
Decision 02 · The numbers had to come to me
Once it was live I had the same three questions every day. Any downloads? Any trials? Anything crashed? Answering them meant a tour of three dashboards, and that's a habit rather than a system. This project is built in the hours around a day job, so anything that needs daily attention does't work.
So I wired App Store Connect, RevenueCat and Mixpanel into Claude. A weekly, routine reads all three and writes me a short report. I don't go looking, and if nothing needs attention I don't open anything.
Feedback runs the same way. The in-app form posts through the server function into an Airtable queue, and an AI pass categorises each entry and ranks it against criteria I set. By the time I read it, it's a prioritised list rather than an inbox.
Reflection
I'd start telling people earlier. Linguease went live with no audience waiting for it, because the build was the half I enjoyed, so it's the half I did. Distribution is harder for me than shipping, and it's still an open problem.
Linguease is the smallest product on this site and the widest scope: positioning, interaction design, a learning system, native code, an App Store review, its own instrumentation. The rest of this site is work done with teams. This is the same job, held alone from start to finish. And it shipped.