Architecture Notes
0 · PoC

The PoC I Ran Before Building Anything — Can Generative AI Alone Make an iPhone App?

2026.07.02~4 min

00Overview

Tools

  • iPhoneTesting on a real devicealready owned
  • Mac (Intel, out of support)Unpacking into Xcode, PoC onlyalready owned
  • ClaudeGenerative AI (Free plan)$0

01Opening

Generative AI is everywhere. I knew that much. What I didn't know was how far it could actually go. Between what I touch at work and what the headlines promise, there is — as always — a gap.

So before starting anything, I decided to find out in the cheapest way possible. A PoC (Proof of Concept). The question fit in one line.

Can generative AI, on its own, build an iPhone app?

02Turn

Zip

What I did was almost embarrassingly simple. I typed this into Claude's chat (claude.ai):

Build an iPhone game in Swift.
Output it as a Zip file.

A few minutes later, a Zip file came out. I downloaded it, unpacked it into Xcode on my out-of-support Intel Mac, plugged in the iPhone over USB, and installed the app.

It ran.

A carelessly requested game ran carelessly well. This is not a story about quality. The fact itself — a working iPhone app, on a real device, from nothing but a chat message, without writing a line of code — felt like watching an era change in front of me.

Product

The PoC passed, so I went for the real thing: build an actual product and see how far generative AI can carry it. That product became the apps at lycoapp.com, and this Architecture Notes is the record of those three months.

I ran the project on the OODA loop (Observe / Orient / Decide / Act) rather than plan-everything-first PDCA. With generative AI the landscape shifts every week, so observe first, judge on the spot, and move — that rhythm fit.

One thing I want to underline: every technology used in this product was new to me. I have used similar things at work, but nothing here was chosen because it was familiar. Each choice was weighed flat against the requirements. So each article should read as a selection record with no strings attached.

03Finale

ADR

The results are kept as ADRs (Architecture Decision Records). The format layers the SCQA framework (Situation / Complication / Question / Answer) on top of MADR (Markdown Any Decision Records): start from the situation, raise the question, line up the criteria, then give the answer, the reasons, the options that lost, and an honest look back — all as one continuous story. This format, too, was new to me.

You won't find step-by-step instructions here, for two reasons. First, the heart of an ADR is "why we decided," not "how to do it." Second, asking an AI for the steps is simply faster. Everything documented here actually runs, so you can hand an article to an AI and say "reproduce this" — it will usually do a fine job.

One step further: this is not just about saving labor. If AI takes over the doing, and the human work shifts toward deciding, then the document worth keeping in product development may not be the design spec at all, but the record of why each decision was made. Watching that era begin through this PoC is what convinced me.

Not the design docs — the record of decisions (ADR)
is becoming the heart of development documentation.

So please read this site as a record of "why it was decided," not "what was done." The road runs like this: 1 AI-driven phone-only development gets you building, 2 Brand foundation prepares a vessel for the track record, 3 Marketing decides what to build, and 4 Monetization keeps the product alive. From here, the actual decisions begin.