Testinha: I built an app with AI in a week. And I still needed my dev skills

I built Testinha, a party game in Portuguese in the style of Heads Up: the phone goes on your forehead, the room gives the clues and a tilt of the phone settles each turn. From the first commit to the last it took six days (October 24 to 29, 2026), 75 commits and a lot of AI along the way. In this post I share what I used, what surprised me and where I still had to do the developer’s work myself.

Want to try it? Testinha is on the App Store and on Google Play.

From market report to specification

Before writing a single line of code, I asked Claude Opus to look at the App Store with the search “heads up”. It read the 11 apps on the results page (nine of them are charades games) and the reviews for each one. The report came back with five recurring complaints:

1. Looks free, then charges. People who downloaded it thinking they wouldn’t pay and got billed for a weekly or yearly subscription.
2. Too many ads. The most frequent complaint on the app with the most reviews in the group.
3. Not in Portuguese, or the topics aren’t Brazilian.
4. Subscription hard to cancel, with refund requests.
5. Abandoned app. One of them had been on the same version since 2017.

An honest limit of this method: the store shows at most about 10 reviews per app, so it’s a small sample. It’s good for spotting patterns, not for proving anything.

The report gave rise to a specification, also written by Claude Opus, using the tlc-spec-driven skill. I had to adjust it, because with only what the AI wrote it wasn’t going to work. Decisions were recorded in a state file, each with its reason and trade-off. One of them, early on: the app is free, has no ads, and the only charge is a one-time purchase for each paid theme, with no subscription. Every complaint in the report became a product rule.

The spec had a gap: it said nothing about what the app should look like.

What I used, piece by piece

Tool	What for	How it went
Claude Opus (with web search)	Report on Heads Up apps and their reviews	Fast and useful, but with a small sample of reviews
tlc-spec-driven (Cursor skill)	Turn the report into spec, design, tasks and validation	Gave the project its backbone: everything was recorded in project files
Cursor + Grok 4.7	Write the code from the spec	Delivered what the spec asked for. Nothing extraordinary, nothing bad
Figma	Redesign the layout from screenshots, colors and references	The part that impressed me the most
Expo (React Native) + TypeScript	The app itself	The project’s foundation, with the same code for iOS and Android
expo-iap	One-time purchase of each paid theme	Works, but can only really be tested in a native build, not in Expo Go
Swift module with Apple Intelligence	Generate words for categories the player creates, on the device itself	A small module, with handling for unsupported devices
Vercel	Theme catalog as remote JSON	Themes, words and prices change without a new app version
EAS Build and EAS Submit	Build the app and submit it to the store	Deployment was smooth

Figma was the surprise

With no layout in the spec, Cursor with Grok implemented whatever it could, and the result worked and looked terrible. That was predictable: when you don’t say what you want, the AI chooses for you.

I took screenshots of the screens that were already implemented and brought them into Figma, along with what I wanted for the layout, the colors and a few references. The very first prompt gave me a very satisfying result, well above what I expected from a first attempt. The improvement in layout and in the animation tweaks was visible from one version to the next.

Figma came in later, when something was already running, and worked as a design reviewer. On my next app, I’d put this step before implementation.

Did it need adjustments? It did. A nice layout doesn’t decide the game flow or the order of the screens. That was on me.

Where the AI fell short

The game flow. The most critical part of the project was deciding which screen leads to which, and what information shows up in party mode and endless mode. In the code this shows up as more than 15 screen phases in the same state machine, and the commit history shows the struggle: a run of changes just to rounds, endless mode, team scoring, the results screen and the tutorial, including removing an entire step I had accepted earlier.

The spec shows the same thing. It has an assumptions table with a “confirmed?” column, and several rows were left unconfirmed, because they were product decisions where the AI could only propose a default. The one who confirms them is the person who’s going to play the game.

The real device. The game depends on tilting the phone, and that can only be properly validated in your hand, with people playing. Sensitivity, vibration, turn timing and touches near the screen edges are things an automated test can’t feel.

The code, through a developer’s eyes

Once it was done, I went and read what the AI had written. Some of it is good, and some of it I wouldn’t keep.

What’s good

• The game logic is separated from the UI, which makes it easier to test.
• There are plenty of automated tests, and the code passes type checking without hacks.
• The architecture decisions are documented in the repository, with reasons and trade-offs.

What I wouldn’t keep

• Duplication. There are two nearly identical versions of the UI. The second one looks like the wide-screen version, copied instead of adapted.
• Huge files. Some go past a thousand lines, and the root component takes on too many responsibilities.
• Mixed folders. Components, rules and tests sit side by side, with no organization by feature.
• Loose colors. The same colors are repeated across several files, with no single theme.
• Small signs of AI: two package managers in the same project.

Things only someone who knows the app stores would catch. The spec only talked about iPhone, but the app runs on iOS and Android, and the Android config requested audio recording and foreground service permissions, in an app that only plays a short sound. A sensitive permission with no use is a reason for questions during store review. A build issue also forced me to block the ACTIVITY_RECOGNITION permission. The AI didn’t warn me about any of this beforehand.

What I’d do differently, and what stays

If I started over today, I’d change four things:

1. Put the layout in the spec from the start, or do the Figma step before implementation.
2. Draw the screen flow in a diagram before asking for code.
3. Write the code organization rules into the spec: folders by feature, a single theme, no thousand-line components.
4. Review every delivery on the device and in the diff, instead of just accepting it.

AI sped up the doing a lot: research, spec, code, layout and even a native Swift module came together in days. But deciding what the product should be, validating it on the device, seeing what the store will question and leaving the code in a state I can maintain are still the job of someone who knows how to build software. If you can’t read what the AI wrote, you’re at its mercy.

If you’re building with AI, tell me in the comments: where did it get things most wrong for you?