Build Your Own Mac App - Prompt Chain

How a non-coder turned a 30-minute spec into a signed Mac app, using nine prompts and zero lines of code

This skill is brought to you by Andrea Chiarelli, Founder of The Art of Asking Questions.

The Origin Story

Andrea has spent over ten years interviewing people for a living, and transcription long ago became part of the daily job. Microsoft Teams, Zoom, Otter and everything like them solve that problem the same way. The audio goes somewhere else to be processed.

Working in the UK with clients who ask reasonable questions about cross-border data processing, that can be a practical obstacle rather than a philosophical one.

He wanted transcription that ran on his own machine and sent nothing anywhere. He started where most people start now, asking Perplexity which speech recognition models could run locally. The answer was confident and broadly correct, so he assumed he could wrap it in a browser tool, which is how he usually builds simple prototypes. When he took that idea to Claude Code, he got a useful reality check. A decent speech model running privately on his own hardware had to be a proper application, not a browser tab.

He had never built a Mac app. He doesn’t write Swift. Still, he spent about 30 minutes working out what the app should do, then said explicitly to Claude Code: don’t build the app, give me a series of consecutive prompts that will build it step by step. He got nine. He pasted them in one at a time over about 45 minutes while watching television, and ended up with a signed, installed Mac app sitting in his dock, having written zero lines of code.

The build used one session of a Claude subscription that Andrea was already paying for, and running the app since has cost nothing. Enjoy.

---

The Problem This Solves

Every transcription tool you use is a decision about where your data goes. Most of the time nobody notices, and today most professionals are reasonably comfortable getting recorded. But some cases and clients are different, and a US-based service processing personal data from the UK is the kind of thing people are right to query.

The alternatives have historically been to pay a provider you trust more, or to have something built for you, which means a specification and a big invoice. There is now a third option, which is to build the tool yourself.

The interesting part is not that AI can write code, which stopped being news some time ago. It is that the skills you need to build a fully functioning app are describing a problem precisely enough, and getting an LLM to break it into manageable stages. Most people can do this. That makes this approach a powerful template. The app Andrea built was for transcription, but the exact same principles apply to pretty much any app you like.

Andrea’s phrase for it is “human in the lead” as well as “human in the loop.” You do the research, you decide what matters, you give it a push in a chosen direction, and then you check where it lands at every stage.

A word for the wise: Homemade apps like this are great to use personally, but you should engage a professional if you intend to use the app in a production or high-stakes context. Don’t run your company’s payroll in a homemade app. Someone always needs to take responsibility.

---

Why The Build Was Broken Into Steps

Asking Claude Code, or Codex, or any other coding LLM to build a transcription app in one go produces an enormous pile of code, which is usually followed by several hours of discovering what is wrong with it. Small, focused prompts avoid that, and the reasoning is the same as it is on a building site. You would never ask a builder to put up a house overnight and then walk in at the end hoping for the best. You inspect the foundations, then the walls, then the roof, because a problem with the foundation is cheap to fix early and close to catastrophic once the roof is on.

Three things follow from working this way. Progress is visible, because something runs or shows on screen after every prompt rather than after two thousand lines of code. Bugs surface where they were introduced, since Claude tests each piece as it builds it, so a problem in step two is fixed in step two instead of being dug out from underneath everything else at step nine. And it is cheaper in practice, because a sequence of small prompts consumes far fewer tokens, and actual energy, than one giant build followed by a series of giant repair jobs.

A single sprawling request is also where LLMs are most likely to loop, fixing one thing while breaking another and burning thousands of tokens per attempt. Step by step, it corrects itself far more reliably.

---

What The App Does

You press record, you talk, and the text appears. There is a word count in the corner, a Clear button, and a Download button that writes a timestamped .txt file into your Downloads folder. A panel on the right lists everything you have saved before, newest first, and clicking one loads it into the same view.

The app is deliberately simple and does exactly what it says on the tin. Now that the scaffolding exists, extending it is easy. A drop zone for audio files would be a natural next addition, since that is how the underlying model works anyway. Or you could make it look prettier. It’s ready to play with.

---

Ready-to-Use Prompt Chain

The full chain is below, so you can paste each step into Claude Code in order. Run them one at a time and let each finish before starting the next.

Always keep in mind that coding agents are probabilistic, so what happens on your machine may be different from what happened on Andrea’s. If anything seems broken or doesn’t quite work, just tell your coding agent, the sooner the better. It can usually fix it.

A note for readers: The prompts below look full of Swift terminology and technicalities. Remember that Andrea’s skill was not to write these prompts. It was to ask Claude to produce them based on his specification and ideas.

Prompt 1. Project scaffolding

Create a new SwiftUI macOS app called "Transcriber" (macOS 13+ target). Add the WhisperKit Swift package (https://github.com/argmaxinc/WhisperKit) as a dependency via SPM. Set `NSMicrophoneUsageDescription` in Info.plist with a real justification string. Keep the app sandboxed and add the microphone entitlement (`com.apple.security.device.microphone`), and also add `com.apple.security.device.audio-input`, that's the separate Hardened Runtime capability microphone access needs once the app is signed with a real identity instead of a Debug ad-hoc one, and it doesn't work without both. Define the model name as a single constant (`"base.en"`) so it's easy to change later. Confirm the project builds and runs to an empty window before moving on.

Prompt 2. Audio capture