Inspiration
I built PetShare after the first time I used a shared pet-transport service to cross the Channel with my dog. The shared service cost £195; the private pet taxis I normally used cost more than £400 just for the crossing. I expected the shared option to be a practical compromise. Instead, the company had not booked a crossing ticket in advance, so we waited for the next available space. The journey stretched into four and a half stressful hours. Passengers were repeatedly complaining, and one woman missed her last train because of the delay.
The hardest part was watching my dog remain in a cage for those four and a half hours. She was not used to crates or cages, she was frightened and stressed, and I was not allowed to take her out. It was upsetting for her and for me.
That experience made the gap personal. Pet owners should not have to choose between an unaffordable private crossing and a shared journey where timing, tickets, animal needs, onward travel, and communication are disconnected. I kept thinking that other people nearby might be making compatible trips, sometimes with empty space, but there was no trustworthy way to see whether our routes, dates, budgets, pet needs, and documents actually aligned.
PetShare grew from wanting to make one possible shared journey understandable before anyone commits—without treating a pet as luggage, forcing strangers into unsuitable matches, or presenting illustrative data as a real booking.
What it does
PetShare is a working, device-local iPhone MVP. It creates a local traveller and pet profile, captures a structured Find or Offer journey, and checks capacity, budget, route, timing, crate needs, owner proximity, and pet compatibility. A hard conflict produces an explainable rejection before any model call.
For the eligible supplied candidate, GPT-5.6 returns a strict structured recommendation, selects a bounded explanation basis, cites supplied facts and calculations, and surfaces material uncertainty. Swift assembles route, price, readiness, and disclosures, then validates the complete result against the eligible input. A timeout, invalid output, offline operation, provider failure, or missing credential uses an explicitly labelled recorded fallback.
The accepted plan becomes an idempotent local room with participants, pets, estimated contribution, readiness owners, and live-versus-fallback provenance. Profiles, settings, pets, drafts, rooms, and trip-management state persist across relaunch.
The differentiating screen is a travel-document checklist for synthetic dog and cat profiles. Using bundled synthetic fixture dates, it surfaces microchip/rabies chronology, the animal-health-certificate issue window, and dog tapeworm timing for return to Great Britain. It links to GOV.UK guidance and explicitly does not claim document verification, legal advice, veterinary advice, carrier approval, or border approval.
How we built it
Codex was the primary engineering collaborator throughout Build Week. It helped translate the founder problem into product and safety contracts, split the implementation into testable Swift packages, build the SwiftUI shell and progressive intent flow, connect device-local persistence, integrate the provider-neutral GPT-5.6 adapter, and create deterministic evals and regression coverage.
The workflow used exact-commit author and reviewer lanes. Independent Codex reviews inspected navigation, data flow, accessibility, privacy, secrets, bundle contents, and claim boundaries. Simulator replay tested the composed journey rather than relying only on previews or package tests. Those reviews led to concrete corrections in trip persistence, navigation, transport-mode selection, document-rule derivation, and live-versus-fallback provenance.
GPT-5.6 is deliberately bounded but meaningful. Deterministic Swift code owns hard constraints, calculations, eligible-candidate construction, route, price, readiness, and disclosures. In the current journey, GPT-5.6 receives one eligible supplied candidate. Strict decoding and validation prevent unchecked output from being presented as live. The current journey does not claim a live marketplace, real inventory, booking, or payment.
Challenges
The main challenge was preserving trust while still letting the model add value. A persuasive model answer must never override a hard incompatibility or invent availability, prices, documents, or rules. That required deterministic preflight, a narrow provider contract, strict schema decoding, candidate-local validation, visible uncertainty, and an honest fallback.
A second challenge was proving composition. Several features worked independently before they worked together. Exact Simulator journeys exposed defects that passing package tests and polished previews did not, so rendered evidence and persistence across relaunch became release gates.
Accomplishments
- Built a real five-part iPhone app rather than a linear presentation fixture.
- Made entered values affect checks, recommendation or rejection, and persisted local state.
- Rejected hard pet conflicts before GPT.
- Returned and explained the eligible supplied plan through a validated GPT-5.6 schema.
- Persisted live-versus-recorded-fallback provenance into the local room.
- Turned bundled demo dates into a clear pet-document preparation checklist without claiming document verification.
- Passed focused app, domain, persistence, validation, adapter, intent, presentation, and eval suites, plus a fresh-checkout Simulator build.
What we learned
The highest-value AI boundary was not letting a model decide everything. Deterministic code is better for hard constraints and calculations; GPT-5.6 is useful for grounding an explanation in the eligible supplied plan and communicating uncertainty. The combination is more useful and trustworthy than either layer alone.
We also learned that a credible demo needs persisted state and truthful failure behavior. A polished result screen is not enough if entered values do not change it, the result disappears after relaunch, or fallback is presented as live.
What's next
The next step is a small, separately governed pilot to learn which compatibility inputs matter, whether travellers trust the document-preparation workflow, and whether manually coordinated shared journeys can be formed responsibly. The roadmap includes user-controlled preference memory and natural-language intent capture while preserving deterministic eligibility checks. Real users, providers, messaging, document handling, booking, payment, identity, privacy operations, and jurisdictional review require separate product and legal gates.
Log in or sign up for Devpost to join the conversation.