How we built a trip planning app in one evening with AI

Last month, I sat down at my desk at about 8pm on a Tuesday evening. By midnight, I had a fully working iOS app — trip planning, expense tracking, friend invites, sat nav integration — running on my phone. No copy-pasting Stack Overflow. No wrangling Xcode for hours. Just a conversation with an AI coding agent.

This isn't a hypothetical. The app is called Rowta, it's on TestFlight right now, and people are using it to plan real trips. Here's how it happened.

The problem with building apps as a side project

I'm a VP at a software company during the day. I don't write production code at work — I lead teams, talk to customers, think about strategy. But I've always built things on the side. The problem is time. Between a demanding job, family, and the general chaos of life, "side project" usually means "thing I think about in the shower and never finish."

I've got a drawer full of half-started Xcode projects. You probably do too.

The thing that changed everything wasn't a new framework or a better tutorial. It was having an AI that could take a product specification and turn it into working code — fast enough that I could ship something in a single evening session.

The setup: a PRD, not a prompt

Here's the first lesson, and it's the most important one: don't prompt an AI coding agent like you'd prompt ChatGPT.

A vague "build me a trip planning app" gets you a vague app. What you need is the same thing you'd give a junior developer: a proper product requirements document. We call it a PRD.

Before I wrote any code — or rather, before the AI wrote any code — I spent about 45 minutes writing a PRD. It covered:

• User stories. Who is using this? What do they need? ("As a campervan trip organiser, I want to add stops to a trip and reorder them by dragging.")
• Data model. What objects exist? Trips, Stops, Expenses, Users. How do they relate to each other?
• UI requirements. Not wireframes — written descriptions of each screen. "The trip detail view shows a list of stops with drag handles. Each stop shows the place name, address, and any notes. Tapping a stop opens a detail view."
• Design system. Colours, fonts, spacing rules. I'd already defined these in a RTDesignSystem.swift file that the AI could reference.
• Technical constraints. SwiftUI only. SwiftData for persistence. XcodeGen for project management. iOS 17 minimum.

The tool: Claude Code

We use Claude Code — Anthropic's command-line coding agent. It reads your entire project, understands the codebase, and writes code that fits. It's not a code completion tool. It's closer to pair programming with a developer who has read every file in your repo.

The workflow looks like this:

echo 'Build the trip detail view according to the PRD. 
Use RTDesignSystem for all colors and spacing. 
Follow the data model in Models/Trip.swift.' | claude -p --verbose

Claude Code reads the PRD, reads the existing code, and writes new files. Typically 3-5 Swift files per task, all following the patterns already established in the project.

Phase 1: Core trip planning (90 minutes)

The first session built the foundation:

• Trip creation and editing
• Stop management with drag-to-reorder
• Place search using MapKit
• Sat nav integration (Apple Maps, Google Maps, Waze)
• Trip lifecycle: planning → active → completed

I gave Claude Code the PRD, pointed it at the design system, and let it work. The first build compiled and ran. Not perfectly — there were two SwiftData relationship issues that needed manual fixes. But the UI was right, the navigation worked, and the data model was solid.

The manual fixes took about 10 minutes. The AI-generated code that compiled cleanly: about 85% of the total output.

Phase 2: Expense tracking (60 minutes)

The second phase added financial features:

• Per-stop and per-trip expense logging
• Three split types: equal, percentage, and exact amounts
• Estimated vs actual cost comparison
• Settlement dashboard (who owes whom)

This is where the PRD really paid off. Expense splitting has edge cases — what if someone leaves the trip? What if a split doesn't add up to 100%? — and because I'd thought through these in the PRD, the AI handled them correctly first time.

Phase 3: Social features (45 minutes)

Friends, invites, and real-time sync:

• Friend code system (6-character codes)
• Trip invite links
• CloudKit sync between devices
• Push notifications for trip updates

The friend code system was fun. I wanted something human-readable — not UUIDs, but codes you could text to a mate. The AI generated a clean implementation using a character set that avoids ambiguous characters (no O/0, no I/l/1).

Phase 4: Convoy tracking (30 minutes)

The cherry on top: real-time location sharing for groups travelling together.

• Core Location background updates
• Arrival detection (within 500m of next stop)
• Map view showing all convoy members

This was the feature that made people say "wait, you built this in one evening?" Background location in iOS is notoriously fiddly — entitlements, capabilities, battery optimisation, the works. Claude Code got it right because the technical constraints in the PRD specified exactly which Core Location APIs to use.

What we learned

1. The PRD is the product

This is the paradigm shift. In traditional development, the PRD is a planning artefact. With AI-assisted development, the PRD is the primary creative act. The better your PRD, the better your product. The AI is the compiler, not the architect.

2. Design systems are non-negotiable

Without a design system, AI produces generic-looking apps. It'll give you system blue buttons and default spacing. With a design system — even a simple one defining colours, typography, and spacing — you get something that looks intentional.

Our RTDesignSystem.swift is about 80 lines. Colours, font sizes, corner radii, padding values. That's all it takes.

3. XcodeGen saves the project file

AI coding agents are terrible at modifying Xcode project files. The .pbxproj format is byzantine, and even small mistakes corrupt the whole project. We use XcodeGen — you define your project in a YAML file, and it generates the Xcode project from your file structure. The AI creates Swift files; XcodeGen handles the rest.

This one decision probably saved us 3-4 hours of debugging.

4. Build often, fix fast

We build after every phase. If something doesn't compile, we fix it immediately rather than stacking errors. The AI is good at fixing its own compilation errors if you feed them back quickly.

5. The 85% rule

About 85% of AI-generated code works correctly first time. The remaining 15% needs human intervention — usually SwiftData relationships, edge cases in business logic, or platform-specific quirks. That 15% is where your experience as a developer matters. You don't need to write the code, but you need to understand it.

Where it is now

Rowta is on TestFlight with real testers. We've had trips planned and expenses split. The convoy tracking worked on a real road trip. We're heading toward App Store submission.

The total development time from empty Xcode project to TestFlight? About 15 hours across several evening sessions. A traditional development estimate for the same feature set would be 6-8 weeks of full-time work.

That's the shift. Not "AI writes code for you" — that's reductive. It's "AI makes it possible for one person with a clear vision and limited time to build real products." The bottleneck moved from implementation to imagination.

Rowta is a trip planning app for campervans. It's coming soon to the App Store. You can sign up for the launch notification at rowta.app.

← Back to blog