"What shall we do with the kids this weekend??"
I used Claude Code and Codex to turn a weekend prototype into Family Activity Finder, a live UK iPhone app. The coding agents handled much of the implementation, debugging and release work. Shipping still took three months of product decisions, evidence checks, privacy work, billing, testing and store review.
I have spent 20 years working in IT delivery, but I am not a software developer by trade. AI coding tools removed much of the manual implementation barrier. They did not own the product judgement or the consequences of release.
That boundary is the useful part of this build.
The family problem I wanted to solve
The same question appears most weekends and school holidays:
What are we actually doing with the kids?
The answer depends on where you live, the children’s ages, the weather, travel time, cost and whether a venue is genuinely suitable. The usual process means checking a forecast, opening Google Maps, searching several websites and working out whether one place suits children of different ages.
I wanted one useful search.
Family Activity Finder takes a postcode, children’s ages and optional filters such as date, radius, budget, transport and accessibility. It returns a short list with age and weather fit, distance, cost guidance, booking information, directions and a map.
The user journey looked simple. Making the results trustworthy enough for a parent to act on was the larger job.
The prototype took a weekend. The product took three months
The first commit landed on 6 March 2026.
The early version was a small web app with an Express backend and OpenAI. A user entered a postcode and an age group, the app checked the weather, and AI produced activity ideas.
The first search worked. A product also needed:
Version 1.0 reached Apple’s UK App Store on 5 June 2026. Version 1.1.1 followed on 29 June with clearer Premium prompts, stronger purchase handling and better venue verification.
The search box took a weekend. The parts that made it safe to release took the next three months.
- real venue candidates
- accounts and usage limits
- privacy controls
- payments and purchase restoration
- native iPhone and Android shells
- app-store disclosures
- monitoring, security checks and reliable tests
Why I used a controlled search pipeline
I could have made the whole search an autonomous agent. I chose a fixed five-stage flow:
The fixed flow reduced cost and delay. It also made failures easier to trace.
One early result recommended what appeared to be an aquatics venue. It was a pond contractor.
The language model had not invented the business. Google Places had matched the search too loosely, then the model wrote polished copy around weak evidence. A better prompt might have softened the wording while leaving the bad source in place.
That failure changed the way I debug AI pipelines:
Find the stage that introduced the weak evidence before asking AI to rewrite the result.
Later quality work added deterministic checks, clearer handling of unsupported claims and automated tests for results the system should reject. Confident prose is never a substitute for a sound source.
- Convert the postcode into coordinates.
- Get a weather forecast for the selected date.
- Turn the family’s needs into controlled activity categories.
- Use Google Places to find real venue candidates nearby.
- Write useful activity cards around the selected candidates.
How Claude Code and Codex shared the work
I set the direction, chose priorities and made the product decisions.
Claude helped with architecture, task breakdown and challenging proposed approaches. Claude Code handled much of the earlier implementation against the repository. Codex joined later for changes, fixes, quality work and release preparation.
The handover between tools mattered less than the handover between each AI session and the real state of the project. AI sessions forget. The repository had to carry the memory.
Four files became the core handover:
Each task set one objective, named the files involved, listed behaviour to preserve and covered edge cases, acceptance criteria, tests and the expected commit.
The prompts gradually became good delivery tickets. Every session opened by reading the current state and closed by updating it. Whenever I skipped the close-out, the next session started cold.
After several successful commits remained only on my laptop, “push the branch” became an acceptance criterion as well. An AI agent will often stop at the edge of the task it was given, even when the next step feels obvious to a human.
- STATUS.md recorded what was true now.
- DECISIONS.md recorded why a choice had been made and what might reverse it.
- ARCHITECTURE.md explained how the parts fitted together.
- DESIGN_SYSTEM.md recorded how the product should look and behave.
The bugs that turned a demo into a product
The most useful failures appeared outside the quick, tidy journeys used in demos.
The search button that stopped working after midnight
I left the Android app open overnight on a physical Pixel.
The following day, the page still held yesterday as its earliest valid date. Hidden HTML form validation rejected the search with almost no useful feedback, so the button looked dead.
The same bug existed in the web and iPhone versions. The Android WebView was the first place it became obvious.
The fix was small: refresh the local date rules when the page loads, returns from the background and submits. The wider lesson was to test changes in time and state, rather than running only journeys that start and finish within 30 seconds.
The paid account that still looked free
A separate race appeared in the subscription flow.
The purchase could be verified and Premium access written to the database. The app then asked for the subscription status again before that write had become visible. The user had paid, but the interface could still look free.
The fix was to trust the authoritative response from the verification process instead of immediately asking a second system for the same state.
This is the kind of bug that appears when money, identity, device state and server state meet.
Why Apple rejected the first submission
Apple rejected the first App Store submission on two grounds in one review.
The reviewer could see the website’s cookie banner inside the iPhone app. The subscription journey also failed to show enough information before opening Apple’s purchase sheet.
Both findings were fair.
The iPhone shell stopped loading Google Analytics, the web cookie banner was hidden inside the native app and the privacy labels were corrected.
The subscription finding forced a larger change. I had assumed Apple’s purchase sheet gave users enough information because it displayed the product and price. The review required the price, billing term and legal links to appear before purchase began.
I built a web-based disclosure screen that reads the live StoreKit price and shows the required information before opening the native purchase sheet.
While recording proof for the resubmission, a fresh sandbox account exposed another activation problem. I fixed the cause before sending the new build back.
The next submission was approved.
Verify the premise before paying the compliance cost
I nearly formed a limited company because I believed publishing as an individual would expose my home address on the UK App Store.
I had misread which storefront rules applied to a UK-only launch. I reversed the decision and recorded the reason in DECISIONS.md, along with the conditions that might justify revisiting it.
AI can help solve a badly framed problem very quickly. Check the premise before spending time and money on the answer.
One codebase still created two release systems
The main product is a web app with two thin native shells around it.
The iPhone version uses a SwiftUI WKWebView and StoreKit 2. The Android version uses a Kotlin WebView and Google Play Billing.
Both platforms talk to the same provider-neutral subscription model. Designing that shared subscription table early avoided a database rewrite when Android arrived.
The product logic was shared. Each store still had its own billing contract, purchase verification, renewal events, test tools, review process and release rules.
I was advised to ship Android without billing and wait to see whether downloads justified the work. That would have left Android users unable to upgrade after reaching the free limit because there is no separate web checkout.
Billing was part of the user journey, so it had to ship with the platform.
I tested the Android flow through purchase, trial, renewal, cancellation, expiry and repurchase, including events arriving in an unexpected order.
My Google Play account then imposed the least cinematic blocker in the project: a closed test with at least 12 opted-in testers for 14 continuous days before I could apply for production access.
The code was ready before the store was.
What Claude Code and Codex did well
Both coding agents were effective when the task was specific and the acceptance criteria were clear. They handled coordinated changes across several files, traced failures through logs and code, repeated an existing contract on a second platform, added tests and explained unfamiliar parts of the stack.
They could also implement a weak decision quickly when the task itself was wrong.
Neither tool could decide whether a venue result was trustworthy enough for a parent. The privacy promise, subscription journey, business trade-offs and release accountability remained mine.
The agents completed a large amount of engineering. I owned the problem, evidence, priorities and consequences.
Five rules I would keep for another AI-assisted app
1. Prove one complete journey first
Start with one painful job and make one end-to-end journey useful before adding more features.
2. Put evidence inside the system
Decide where factual evidence enters the flow, where it is checked and which claims the model is allowed to make around it. A confident response cannot repair weak source data.
3. Keep project memory beside the code
Record the current state, architecture, design rules and reasons behind decisions in files that every new session must read. A long chat is a poor project record.
4. Treat release work as product work
Accounts, payments, privacy, analytics, monitoring and app-store rules shape the user experience. Leaving them until the end creates a prototype with a long and expensive tail.
5. Set the success gate before expanding
Shipping gives me a chance to learn. It does not prove the business works.
The next decision gate for Family Activity Finder is 100 paying families before I consider another country. Until then, it is a shipped product and an ongoing commercial test.
Where Family Activity Finder stands now
The iPhone app is available on Apple’s UK App Store. Premium costs £3.99 a month after a seven-day free trial and includes unlimited searches, multi-age search and more filters. An iOS 1.2 update has also been submitted to Apple.
Android is in closed testing. A signed Android 1.2 build is prepared and committed, but that build has not yet been uploaded to Google Play.
The last recorded quality pass had 139 tests passing, service worker cache version 39 and a successful production smoke check.
The important unknowns sit outside the test suite:
I am not calling it a validated business because the evidence does not support that claim yet.
- whether families return
- whether venue quality holds across the UK
- whether the subscription journey converts
- whether enough people value the result at £3.99 a month
Can a non-developer ship a real app with AI coding agents?
Yes, if they bring enough technical judgement, product ownership and persistence to manage the work around the code.
Claude Code and Codex removed a large amount of the manual coding barrier. They helped me work through unfamiliar technology, build across several systems and reach a real app store.
The tools did not remove the need for evidence checks, testing, privacy decisions, payments or release ownership. AI made the work move faster. I remained responsible for the result.
Try Family Activity Finder or view it on Apple’s UK App Store.