I'm a designer who built an app with AI. Here's what that actually means.

When people hear "I built an app using AI" they imagine one of two things.

Someone who vibe-coded a prototype over a weekend and is now calling themselves a founder. Or someone who used autocomplete on a few functions and is overselling it.

What I did was neither.

Where I started

Ten years of product design. I can read code. I understand systems, data flow, and edge cases.

But I had never shipped a production iOS app. I did not know SwiftUI cold. I did not know APIs at a practical level — rate limits, auth, retries, caching.

I knew what I wanted to build. I had to learn how to build it.

That gap is where AI became useful — not as a shortcut around thinking, but as leverage once the thinking was clear.

The first months were humbling

ChatGPT. SwiftUI tutorials. Describe what I want, paste the output into Xcode, watch it break, paste the error back, iterate.

That loop was my entire workflow for months.

It was slow. I threw away whole features when I realised the architecture was wrong. I rebuilt the same screen four or five times.

But the failures were the education. Every rate-limit error taught me about batching. Every hallucinated API taught me to verify before I shipped.

By month three I was not copying output anymore. I was directing it.

The shift that changed everything

Early on I used AI like a search engine with better syntax. "How do I do X in SwiftUI." Useful, passive.

Later I treated it like a team of specialists I was managing: a brief, constraints, a definition of done — then critical review of the output.

The difference is enormous. The first approach makes you dependent. The second makes you faster.

I started writing what I call spec files — markdown that defines how a screen should behave, what data it needs, what edge cases matter. Then I handed that to Cursor and iterated on the result.

That is not traditional engineering. It is product thinking applied at implementation depth.

The tools and what they were actually good for

Cursor — primary environment. Talking about the whole codebase changes how you fix bugs and add features.

Claude — architecture, data models, debugging logic, dense prompts.

Gemini + Perplexity — orchestration and live context inside Planark's pipeline, not generic chat.

ChatGPT — quick lookups and variations when speed mattered more than depth.

v0 — early UI exploration. Describe a screen, get a prototype in minutes. Not for production — for learning what you actually want before you commit.

Figma — design system and brand. Visual language first, then implementation. Later, design context flowing into the codebase.

Midjourney — brand direction. The vintage postage-stamp aesthetic came from exploration I would not have reached with a standard moodboard.

What AI could not do

Every time I gave it too much freedom — "build me a trip planner" — the output was generic, safe, and wrong.

The product decisions were mine. The information architecture. The Loops tab hierarchy. The scoring and time-of-day logic. What belongs on a discovery surface with no AI at all (Around is pure Wikivoyage geography) versus what needs orchestration in the wizard.

AI made me faster at building what I decided. It did not replace the deciding.

If anything, faster implementation meant I needed clearer thinking about which directions were worth exploring.

The API problem nobody warns you about

Wikivoyage. OpenStreetMap. Government feeds. All free, all useful — and all subject to rate limits that will ruin your day if you do not plan for them.

Early on I made too many concurrent calls. Fine in testing. Painful under real usage.

The fix was systematic: chunking, backoff, caching, never fetching the same thing twice in one session.

None of that shows in the UI. It is the difference between an app that works and one that embarrasses you on a demo with spotty signal.

That forced me to think like an engineer about scale — and it changed how I approach product decisions in general.

The prompt engineering chapter

Where AI does run inside Planark — itinerary enrichment, tips, narration scripts — the pipeline took longer to get right than almost anything else.

Early versions were too verbose, too generic, occasionally wrong in ways that would erode trust.

Getting it right meant hard constraints: what does the model actually know? What can we verify before showing it? Where do we need explicit guardrails against hallucination?

I also learned to think about cost. Tokens are not free. A sloppy prompt is money at scale.

By the end, prompts read less like chat and more like product specifications — dense, repeatable, testable against real places.

What a year of this produces

The code is imperfect in places. A year of learning shows in the seams.

Underneath is a year of real product thinking: a discovery model grounded in open data, a trip builder that respects geography, a trust model that does not depend on affiliate revenue.

The thinking is what matters. The code can be refactored. The intuition behind it took a year to develop.

What I built is not impressive because of the technology stack.

It is impressive because one person — without a traditional engineering background — learned enough about systems, APIs, LLMs, and travel data to ship something that actually works.

By refusing to be passive about the tools available.

That is what building with AI actually means. Not less thinking. More.