TapThatApp

TapThatApp

I've had simple game ideas in my head for years, despite not being a gamer. Recently, I asked how I can make those ideas a reality and test a new way of working: could one designer, working with AI, take an idea from a single prompt to a live, monetised product on the App Store?

Designed and Built by

Jarrod Moore

Colorful hero image of a landing page inside TapThatApp

INTRODUCTION

TapThatApp… An app built for myself by myself, which has now evolved off the back of conversations and feedback received from people after watching them play. A huge part of the App's evolution has been the 4th game 'Math Madness' which I was inspired to create as a way to help my son improve his times tables, pattern recognition, memory recall, all while having fun. It was a game changer, pun intended!


THE GOAL

I've spent my career designing software the traditional way, which is no bad thing. Research, flows, wireframes, Figma files, handoff, waiting. I'm good at it. But a question kept pressing me:

If all of that process now lives in my head, do I still need the process? And how fast could I build and ship without it?

That's a business question disguised as a design question. Every stage of the traditional process exists to create shared understanding and alignment across a team, and every stage costs time. Time is the most expensive thing a new idea can consume.

Most designers aren't blocked from shipping by their design ability. They're blocked by:

  • Engineering resource

  • Technical knowledge

  • Process ceremony

  • Tooling handoffs

I wanted to prove those blockers are now optional. So I set a test with real stakes: get TapThatApp approved, live, and earning on the App Store, all by myself.

The questions I had to answer:

  • Can I skip the artefacts and go straight to working software without losing quality?

  • Where does senior judgement earn its keep when AI handles execution?

  • What am I willing to sacrifice to ship, and what's non-negotiable?


MY APPROACH

Define success first

As always, I set the main goals up front:

  • Live on the App Store. Approved, searchable, real

  • Fully built by myself. No engineers, no designers, no agency

  • Launch fast. Submit within 5 days

  • Monetised. A working business layer, not just a launch

Deliberate constraints

The tightest constraints were self-imposed, because constraints force clear decisions:

  • No budget, evenings only. Every step had to justify itself against "live on the App Store"

  • No Figma. All design decisions (UX and UI) happened in working code, not pictures of code

  • No Swift experience. AI carried implementation; I owned direction, judgement, and quality

  • Smallest fun thing. Two game modes for v1, everything else deferred

Prototype in minutes, not days or weeks

I could do it quick, because I knew what I wanted:

  • One prompt produced a working HTML prototype

  • I was playing the game within 5 minutes, not reviewing mockups of it or having multiple meetings talking about it

  • I designed by playing: notice what feels flat, fix it, play again

  • Every element earned its place this way: two game modes, the dark theme, celebration moments, 30+ humorous end-game comments


Two HTML versions from my first prompt


Go native in Xcode

Once it felt right, not only by instinct but by experience, I moved to native SwiftUI via Claude Code. The prototype was the spec. Here's what I skipped, and why it held up:


Stage

Traditionally

What I did instead

Why it held up

Research

Surveys, interviews, audits

Built it by myself for myself first, then validated with real players

A live app is cheaper and more honest than a research deck

Wireframes

Lo-fi screens, flow diagrams, presentations

Straight to a playable prototype

Playing surfaced problems faster than diagrams

Hi-fi design

Figma files, specs

Designed in code, by feel and experience

Design and product were never out of sync

Handoff & QA

Tickets, back-and-forth

Prototype was the spec; I was QA on device

Zero translation loss


Takeaway: experience let me compress every stage whose only output was shared understanding. With a team of one plus AI, shared understanding is free. What can't be compressed is judgement: when the game feels flat, when the timing is off, when the copy tries too hard. That was my whole job and where I focused my time and attention.


Iterations done in SwiftUI (Xcode) after a few refinements


PROJECT CHALLENGES


  • The race condition. Scores in Beat the Best randomly failed to save. Two timers were racing each other. AI wrote the fix, but only after I diagnosed the problem. Prompting harder wouldn't have found it.

  • Launch screen frustration. The app logo refused to appear from device home screen to launch screen as I intended because two Xcode settings were silently overriding each other. Hours disappeared trying to fix it.

  • Rejected by Apple. v1.0.0 was rejected over review notes, age rating, and a missing support URL. I fixed all three without touching the build and skipped days of review queue. Knowing what doesn't need a new binary is critical knowledge.

  • A typo that cost a week. I cancelled a submission to fix one misspelled word in a screenshot and lost my place in the review queue. Painful lesson, permanent habit: triple-check before submit.

  • Code signing craziness. Keychain prompts, "Command CodeSign failed", certificate regeneration. After all that, the logs revealed the real culprit: a network timeout. Lesson learned early: read the logs, don't trust the error message.


First AI output version on the splash versus my struggle trying to perfect it in Xcode. AI did inspire the final version in terms of the App Icon


After the excitement of my first app store submission… Rejection!


KEY DECISIONS

The calls that shaped the product, and what each one bought:

  • Cut iPad support entirely. Screenshot requirements, orientation handling, and review risk for a device few would use. I traded reach I didn't need for a faster path to approval. It still runs on iPad in compatibility mode, where the kids can still use it if they prefer.

  • Launch screen. I eventually found the fix, then made the smarter call: ship v1.0.0 without it, polish it in v1.1.0. This trade-off helped keep the momentum even though this mattered to me.

  • Ads before in-app purchases. Interstitials validated the entire monetisation pipeline with zero purchase friction on day one. Remove Ads was deferred until there were users worth converting. Revenue sequencing, not feature sequencing.

  • Treated shipping operations as design work. Listing copy, screenshots, privacy policy, AdMob setup, tax forms. The unglamorous 40% is half of shipping, and owning it removed my last dependency on anyone else.

  • Deferring Android Development. My goal was to ultimately do something for myself and validate ways of working, so as an iPhone user I went with the path of least resistance to meet the goal.


CORE OUTCOMES

TapThatApp was submitted to Apple within 4 days and is now live on the iOS App Store:

  • 2 launch modes for v1.0.0: Fastest Fingers, a race against the clock, and Beat the Best, a countdown against your own record

  • 4 game modes by v1.2.0: Added Pop the Dot and Math Madness

  • Moments that reward: Confetti for podium finishes, fireworks for personal bests

  • Sound: SFX for added sensory immersion and tension

  • Copy with attitude: 30+ cheeky end-game comments, and a listing subtitle that got as much iteration as any screen: "Fingers and complicated feelings."

  • High scores: A leaderboard to see how you have improved and to challenge yourself further

  • Sharing: Acquiring new users through competitive score sharing and bragging rights


4 games available on the app store: Fastest Fingers, Beat the Best, Tap the Dot, Math Madness


Share cards for bragging rights and organic user acquisition


Under the surface sits everything a real product needs:

  • Game state management and sound design

  • Ad integration with App Tracking Transparency

  • A working payment pipeline

  • Three approved releases within a month, each shaped by watching real people play and personal needs


Video of gameplay for the 4 games currently in production


ULTIMATE IMPACT


Measure

Result

Idea to App Store submission

4 Days, against a 5-day target

Releases shipped

v1.0.0 through v1.2.0, all approved

Team size

One

Monetisation

AdMob live in production, payments operating

Early signal

5-star review at launch; other parents telling me their kids love playing


FOR BUSINESS:

This validated a new cost structure for taking ideas to market. Work that traditionally needs a designer, engineers, and weeks of process was delivered by one person in days, monetised from day one. That's not a productivity gain. That changes how many ideas a business can afford to test.

FOR DESIGNERS:

The bottleneck was never design ability, it was everything around it. Senior experience doesn't disappear when AI handles execution. It relocates:

  • From producing artefacts to making calls

  • From documenting intent to judging quality

  • From waiting on others to owning the whole pipeline

  • From repetitive time consuming tasks to dreaming again

The unexpected return.

Shipping generated ideas faster than planning ever did:

  • I planned for 1 game but shipped 4

  • At least five new game concepts surfaced from watching people play

  • A clear case for in-app purchases in the next release

  • A marketing experiment queued with Apple Search Ads, using the same "smallest real test" philosophy

The question that started this was whether I still needed the process now that the process lives in my head.

The answer is on the App Store. Go play!


THE FINAL VERDICT

There are many key learnings and takeaways, but here are a few:

  • Just try. Testing an idea beats thinking about it. Every time.

  • The prototype is the spec. Ship something playable to communicate. Let documentation follow, if it's needed at all.

  • Senior experience relocates, it doesn't disappear. AI handles execution. My job became the calls: what to cut, when it feels right, what's good enough to ship.

  • Learn the boring parts once. App Store Connect, monetisation plumbing, review guidelines. Embrace them and they stop being a dependency.

  • Don't resubmit for a typo. One rushed screenshot cost me a week in the review queue. Now everything gets triple-checked before submission.

  • Play without pressure. Building something purely for myself brought some fun back to product design, and the creativity followed.

  • The limitation mindset is gone. My ideas no longer have to stay in my head. If I can imagine it, I can build it.

  • Process. Following a good process is necessary whatever is needed for the job, but now it looks very different: idea, build, play, ship, play, then watch the plan come together.


App Store listing images and overall brand UI