We will be undergoing planned maintenance on Oct 7th 6:00AM UTC / Oct 7th 2:00AM ET

Fitareeaee — GPT-5.6 Ride & Delivery Planner

Describe a ride or delivery in English or Arabic; GPT-5.6 drafts it, you review it, and deterministic code explains every real match.

Comment

Inspiration

A community ride or package delivery often begins with one simple sentence: “I need to get from Dallas to Austin Monday morning,” or “Can someone carry a small package next week?”

Most marketplace applications immediately force that request into a long, rigid form. Even after completing it, users are often left guessing why one result was selected over another.

I wanted to preserve the flexibility of conversational AI without allowing a probabilistic model to control consequential decisions. That became the central idea behind Fitareeaee: let people describe a ride or delivery naturally, convert that intent into a structured plan they can review and correct, and then show transparent matches based only on real marketplace data.

The goal was not to build another travel chatbot. It was to create a practical rideshare and delivery marketplace in which AI makes the interface easier while deterministic software remains responsible for operational decisions.

What it does

Fitareeaee is an Android marketplace for community rides and package delivery, enhanced by a review-first GPT-5.6 planning workflow.

From the Home screen, a user can describe a ride or package request or offer in English or Arabic. For example:

I need a ride from Dallas to Austin on August 10 at 9:00 AM for two people under $40, no smoking.

GPT-5.6 converts that natural-language request into a strict, structured draft containing:

  • Request or offer intent
  • Ride or package type
  • Origin and destination
  • Date and departure time
  • Number of passengers or available seats
  • Package details
  • Budget
  • Preferences
  • A concise summary
  • Missing information or clarification questions

The result is clearly labeled AI draft — review required. Every operational field remains editable, and nothing is saved, matched, or booked until the user explicitly confirms the draft.

After confirmation, deterministic application code searches only real Firestore marketplace records and ranks compatible results. GPT-5.6 interprets the user’s language, but it does not select a person, fabricate availability, or control ranking authority.

Each result explains why it matched, including:

  • Route compatibility
  • Departure time
  • Seat or capacity availability
  • Price and budget fit
  • Preference compatibility

If no compatible record exists, the application presents an honest empty state rather than inventing a trip.

The workflow continues into full Trip Details and fictional manual-verification context. A new selection creates only a payment required state. It does not decrement seats, confirm the booking, or unlock participant chat.

Because the contest build does not claim a live payment processor, a separate fictional paid-and-confirmed fixture demonstrates participant-only chat without pretending that a real transaction occurred.

Fitareeaee also includes:

  • Separate Request a ride or delivery and Offer a ride or delivery actions
  • Interactive origin and destination map pins
  • English and Arabic speech input
  • Accessibility read-back
  • Editable local recurring-plan templates
  • Verification progress
  • Completed trips and ratings
  • GPT-5.6 support with a human-escalation path

What makes Fitareeaee different is the boundary between AI interpretation and operational authority.

GPT-5.6 handles flexible human language. Deterministic code controls matching, verification, payment state, booking, inventory, trip lifecycle, and chat access. This keeps the experience conversational without making consequential decisions opaque or non-reproducible.

How we built it

The Android client is built with Flutter, Dart, Riverpod, and GoRouter. It communicates with Firebase Authentication, Cloud Firestore, Firebase Storage, and authenticated Firebase Cloud Functions.

When a user submits a natural-language request, the Flutter client sends a minimal authenticated callable request to a Firebase Function.

The Function uses:

  • The official OpenAI Node SDK
  • The OpenAI Responses API
  • GPT-5.6
  • Strict JSON Schema structured output
  • Independent server-side validation
  • Contact-detail and link redaction
  • Per-user throttling
  • Input and output limits
  • Timeout handling
  • Safe error mapping
  • store: false
  • An app-scoped, privacy-preserving safety identifier

The OpenAI API key is stored in a managed server secret. It never ships inside Dart code, Git history, application logs, Android resources, or the APK.

Model output is treated as untrusted input. Even though GPT-5.6 returns a strict structured response, the server validates every field again before returning the draft to the application.

After the user reviews and confirms the draft, deterministic Dart code filters and ranks real Firestore records. Server-authoritative Cloud Functions and restrictive Firestore and Storage rules enforce:

  • Authentication
  • Ownership
  • User roles
  • Verification requirements
  • Trip state
  • Booking state
  • Seat inventory
  • Payment boundaries
  • Participant-only chat access

Codex was my primary engineering collaborator throughout Build Week. It was not used as a one-shot code generator.

With Codex, I:

  • Audited the inherited Flutter and Firebase repository
  • Preserved an honest pre-Build-Week baseline
  • Traced schema, routing, authorization, and lifecycle defects
  • Implemented and reviewed the GPT-5.6 planning workflow
  • Threat-modeled booking, verification, and chat access
  • Hardened Firestore and Storage rules
  • Added transactional booking boundaries
  • Wrote Flutter, Functions, rules, and lifecycle tests
  • Built and tested Android artifacts
  • Verified the publicly downloadable APK
  • Maintained dated implementation and release evidence

I retained responsibility for the product direction and engineering decisions. I chose the problem, the Apps for Your Life track, the review-first AI boundary, deterministic matching, privacy exclusions, payment limitations, safety constraints, architecture, and final release scope.

Fitareeaee existed before Build Week as a Flutter and Firebase marketplace prototype. I do not claim the inherited authentication, profile, marketplace, chat, or prototype interface work as new.

During Build Week, I added the central GPT-5.6 planner, English and Arabic structured intent handling, speech entry, review and edit boundaries, deterministic explainable matching, official server-side OpenAI integration, privacy minimization, retry and manual fallback, interactive map pins, payment-gated server-authoritative booking, verification and authorization hardening, restrictive data rules, expanded tests, Android release gates, and dated evidence.

The repository preserves a pre-Build-Week baseline tag and an append-only progress record so judges can clearly distinguish the new extension from the inherited application.

Challenges we ran into

The hardest challenge was not connecting the application to GPT-5.6. It was deciding exactly where the model had to stop.

A natural-language planner can influence real-world transportation and delivery decisions. That means model output cannot be treated as authoritative simply because it follows a schema.

I designed the system so that:

  • GPT-5.6 never approves identity
  • GPT-5.6 never declares a person or trip safe
  • GPT-5.6 never modifies seat inventory
  • GPT-5.6 never confirms a booking
  • GPT-5.6 never unlocks participant chat
  • GPT-5.6 never guarantees availability
  • GPT-5.6 never fabricates marketplace records

Structured model output is still validated again on the server, and operational decisions remain deterministic and testable.

The second major challenge was transforming a broad inherited prototype into one coherent judge path without claiming previous work as new.

The existing application contained inconsistent client and backend schemas, legacy prototype paths, broad data-access assumptions, incomplete lifecycle handling, and simulated financial surfaces that could not be presented responsibly.

Resolving this required:

  • Reconciling Flutter, Firestore, and Functions schemas
  • Moving booking transitions to server-authoritative transactions
  • Restricting verification decisions
  • Hardening chat access
  • Removing or excluding misleading prototype features
  • Preserving the pre-existing baseline
  • Building a focused end-to-end user journey
  • Testing the exact public Android artifact on a physical device

Another challenge was balancing convenience with privacy. Natural-language requests can accidentally contain phone numbers, email addresses, or links. The backend therefore redacts likely contact information before sending the request to OpenAI and sends only the minimum context required for planning.

Accomplishments that we’re proud of

  • Built a meaningful GPT-5.6 workflow that changes the product’s primary interaction
  • Created one reviewable schema for English and Arabic ride and package requests and offers
  • Separated AI language interpretation from deterministic operational authority
  • Implemented transparent matching reasons instead of opaque model-generated recommendations
  • Ensured that empty marketplace results remain empty rather than fabricating trips
  • Added a usable manual fallback when AI or network access is unavailable
  • Implemented server-authoritative pending-payment booking
  • Kept seat inventory and participant chat locked until trusted confirmation
  • Added privacy minimization, contact redaction, throttling, strict validation, and safe failure handling
  • Hardened Firestore and Storage authorization rules
  • Preserved an explicit pre-Build-Week baseline and dated evidence trail
  • Published a public Android judge artifact with repeatable testing evidence

The final v1.0.18 judge build passed:

  • 50 Flutter tests
  • 33 Firebase Functions contracts
  • 9 authorization-rules tests
  • 10 two-account lifecycle integrations

The exact public APK was downloaded again, matched against its recorded SHA-256 digest, installed, cold-launched, and tested on a physical Moto G Play.

As a first-time builder with no previous experience creating this type of production-oriented AI application, I am especially proud that the final result is not only functional, but also documented, testable, privacy-conscious, and honest about its limitations.

What we learned

The most important lesson was that AI is most useful here as an interface to human intent, not as the authority over identity, safety, inventory, or transactions.

The strongest architecture was not “let the model do everything.” It was combining GPT-5.6 language understanding with deterministic rules that are reproducible, explainable, and testable.

I also learned that structured output is not the same as trusted output. Model responses still require validation, bounded permissions, error handling, and explicit user confirmation.

Working with Codex also changed how I approached software development. As a first-time builder, I learned how to direct an engineering workflow instead of simply requesting generated code. I had to define requirements, question implementations, evaluate tradeoffs, reject unsafe approaches, reproduce failures, and require evidence before accepting a release.

Finally, I learned that trustworthy hackathon work requires scope discipline. Pre-existing work must be clearly disclosed, claims must match evidence, and unfinished or misleading prototype features should not appear in the final judge path.

What’s next for Fitareeaee — GPT-5.6 Ride & Delivery Planner

The next priorities are:

  • Stronger multilingual personally identifiable information detection
  • Firebase App Check enforcement
  • Operational monitoring and alerting
  • Improved location autocomplete and normalization
  • Broader Arabic interface localization
  • Accessibility testing across more Android devices
  • Better marketplace-density and empty-state guidance
  • More robust trust and safety operations
  • Expanded automated end-to-end device testing

A real payment system would require a separate compliant product, security, and regulatory effort. It is intentionally not presented as complete in this submission.

Longer term, Fitareeaee could become a multilingual coordination layer for local transportation and package delivery, particularly for communities where informal requests already happen conversationally but existing marketplace forms remain difficult, inaccessible, or opaque.

The core principle will remain the same: use GPT-5.6 where language is difficult, deterministic software where consequences matter, and keep the user in control.

Built With

Share this project:

Updates

Submission history