What if you could build your own version of an app you pay for every month?
I tested that with REA, short for Reverse Engineer Anything, and Wispr Flow, the app that turns speech into text. In this walkthrough, I go from installing REA to testing my own Mac dictation app: hold a key, speak, and paste the result into another app.
What REA actually does
REA gives your AI coding assistant tools to investigate how software works. Depending on the target and the tools installed, that can include app files, JavaScript, native binaries, and runtime behavior. Your assistant uses the findings to explain a feature and help build your own implementation.
The connection is called MCP. Think of it as the bridge that lets your coding assistant use REA’s tools.
For this project, the goal is simple: a personal dictation app with a keyboard shortcut, microphone capture, speech-to-text, and text insertion. Start with that useful core, then add features. This is a first working version, not every feature of the commercial product.
1. Get your Mac ready
Here’s what you need for this walkthrough:
An AI coding assistant. I use Claude Code in the walkthrough. Follow its official quickstart if you need to install it and sign in. REA also supports other agents, including Codex and Cursor.
Node.js and npm. Install the current Node.js 24 LTS release. npm comes with it and runs REA’s setup command.
Xcode. Install Apple’s Xcode, open it once, and finish its initial setup. It builds the native Mac app.
A reference app. For the same example, download Wispr Flow and move it into Applications.
Create a new project folder called My Dictation App and open it in your coding assistant. Keep the new project separate from the reference app.
REA is open source. Your AI assistant and any optional analysis tools may have their own costs. Use software you’re authorized to inspect, and create your own code, name, and branding.
2. Install REA and connect it
The easiest starting point is to give your assistant the official repository and this prompt.
PROMPT · Install REA
Help me install REA from https://github.com/morluto/rea and connect it to this coding assistant. Check the requirements, explain any extra tools needed, and show me the setup changes before applying them. Confirm that REA is connected when you’re done.
Prefer doing it yourself? Open Terminal on your Mac and run:
npx rea-agents@latest setup
Choose the assistant you use, review the proposed configuration changes, and approve them. Then restart that assistant and open your project again. The official setup guide has the current instructions.
Some native-app investigations need an analysis engine such as Hopper, Ghidra, or IDA. Let REA identify what your task needs before installing extra tools.
REA connected to the coding assistant in the walkthrough.
3. Ask it to understand one feature
Give REA the reference app’s location and a specific job. You can drag the installed app from Finder into your assistant, or provide its path. For this example, that is usually /Applications/Wispr Flow.app.
PROMPT · Understand the dictation workflow
Use REA to inspect the dictation workflow in /Applications/Wispr Flow.app. Explain the keyboard shortcut, microphone capture, transcription, and text insertion. Separate confirmed findings from assumptions. Don’t modify the original app. Propose a simple version I can build myself.
In the video, the assistant breaks the app into those four parts and calls out what it couldn’t confirm. That breakdown becomes the starting point for the build.
You can use the same approach with other supported software, but narrow the request to one feature first. “Understand how this app searches notes” is a much better starting point than “rebuild everything.”
4. Make the plan local before you build
This was the biggest correction in my demo. The first plan included cloud services and a backend. I wanted a personal app that could handle dictation on my Mac, so I changed the plan before building.
PROMPT · Keep version one local
Turn those findings into a build plan for a native Mac dictation app. Keep speech recognition on-device, with no account, cloud transcription API, or backend. Use original code and branding. Start with a hold-to-talk shortcut, transcription, and paste into the active app. Explain any model downloads or hardware requirements before building.
My project ended up using FluidAudio for local audio processing. It’s a Swift toolkit for on-device audio AI, so you don’t have to build the speech engine from scratch.
Ask for a short build plan and a README, the file explaining how to run your project. Check that both match what you want.
Review the plan before building. In the video, I replace the initial cloud-based proposal with a local Mac version.
5. Build and launch version one
Once the plan looks right, tell your assistant to build it.
PROMPT · Build the first version
Build version one from the approved plan. Run the tests, fix build errors, and give me the exact steps to launch it on this Mac. If you need a missing tool or permission, explain why before continuing.
In my project, the assistant generated an Xcode project and built a native Swift app. Your filenames and commands may differ, so use the instructions it creates for your project.
If it uses XcodeGen, ask it to check whether that tool is installed, generate the .xcodeproj, and tell you where the file is. Open that project in Xcode, select the app’s scheme and My Mac, then click the Run triangle.
The generated Mac project open in Xcode, with FluidAudio as a package dependency.
6. Allow the permissions, then test it
A dictation app needs access to your microphone. Depending on its implementation, it may also request Accessibility to insert text and Input Monitoring to detect a global shortcut.
Open System Settings → Privacy & Security and enable the permissions requested for your new app. Relaunch it if macOS asks.
Then try this:
Quit the original reference app so it can’t answer the same shortcut.
Open Notes or a browser text field and click where you want the words to appear.
Hold your app’s shortcut. In my demo, it’s the Fn key.
Say: “This is my first test of my own dictation app.”
Release the key and check the inserted text. If it’s copied to the clipboard instead, press Command-V.
Testing the new app in a browser text field during the walkthrough.
After the model has downloaded, repeat the test with Wi-Fi off to check that your version really handles transcription locally. The finished app’s local processing is separate from the AI coding assistant, which may still send prompts and project context to a cloud service while you build.
If something fails, give your assistant the exact error and what you expected to happen. For example:
The app hears my voice and creates a transcript, but nothing appears in Notes. Check Accessibility permission, clipboard handling, and text insertion. Fix that without changing the working transcription.
7. Make it useful for you
Now you have something concrete to improve. Add one feature at a time:
PROMPT · A recording indicator
Add a small indicator that shows when the microphone is recording. Keep it out of the way and let me cancel a recording with Escape.
PROMPT · Copy-only mode
Add a setting that copies the transcript to my clipboard without pasting automatically. Show a brief confirmation when it’s ready.
PROMPT · Your next project
Use REA to understand how [app] handles [one feature]. Explain what you can verify, then plan an original version for my project. Keep the first version small enough to test.
That’s the process: understand one useful workflow, make a plan, build it, test it, and improve it. You don’t need to recreate an entire company’s product to make something valuable for yourself.
Marcin
P.S. If you want to try builds like this with other people, come hang out with us in AI Builders. We work through the tools, the prompts, and the parts that don’t work on the first try.