Neuron
YolYoldaş addresses the difficulty of finding and coordinating shared rides between cities in Azerbaijan. Passengers may struggle to find a trip that fits their route, schedule, budget, and seat needs, while drivers may have empty seats and no simple way to manage requests. The app brings both sides together: passengers can find and request rides, drivers can publish trips and respond to bookings, and confirmed participants can message each other. If a passenger needs a different pickup or drop-off, the route and fare can be recalculated, with affected passengers’ consent required for the change. This application is for people who travel between regions in Azerbaijan, and is designed to make their life much easier.
Preliminary score
- Value for the user15.0 / 25
A specific problem and a clear outcome from solving it.
- Prototype and use of AI13.0 / 30
A working core scenario, and what AI actually contributes to the result.
- Quality testing9.5 / 20
Tests, examples of failures, and comparison with the current approach.
- Feasibility6.5 / 15
Data requirements, running costs and a clear next step.
- Originality4.5 / 10
A meaningful difference from common solutions.
What the judges wrote
- Claude Opus 5.5Preliminary45/100
- Strengths
- Your problem is concrete and local: intercity travellers in Azerbaijan who struggle to find rides, and drivers with empty seats. The prototype appears substantial, with a full stack (React, Express, Prisma/PostGIS, Socket.IO messaging, OSRM routing) and a demo mode that runs without credentials. The pickup/drop-off change flow, which recalculates route and fare and requires consent from affected passengers, is a thoughtful touch beyond a basic listing app. Your testing notes are honest: you name the real failures you hit (CORS, schema drift, a ride-creation transaction timeout) and say clearly what was not verified end to end.
- To improve
- AI is not yet central to the result. Ride search falls back to rules when GPT-4o-mini is unavailable, so show what the model does better, for example parsing free-text requests or smarter matching, with side-by-side examples. This track asks for a business workflow and a named adoption metric, so define one, such as seat fill rate, time-to-match or booking conversion, and measure it on your demo data. Compare your matching with how people find rides today (Telegram/WhatsApp groups, bus stations) using a small set of test queries and their failures. Add running costs per search, a data plan for real rides and identity verification, and a concrete next step such as a pilot on one intercity route.
- GPT-6 AstraPreliminary52/100
- Strengths
- Your project addresses a concrete local coordination problem for intercity passengers and drivers in Azerbaijan. Requiring affected passengers’ consent for route and fare changes is a thoughtful feature beyond basic ride listings. Your testing report identifies specific integration failures and clearly distinguishes fictional demo behavior from unverified live-service functionality.
- To improve
- Show an API-mode journey from search through booking and messaging, including what GPT-4o-mini contributes beyond the rule-based fallback. Provide reproducible matching tests, their results, and a comparison with today's manual ride-finding process. For the enterprise track, identify a business workflow owner and an adoption metric such as booking-handling time or seat occupancy. Add estimated operating costs, a plan for protecting account and location data, and a concrete next step toward a live pilot.
The team
Kanan Asadli
developer
Said Yolchiyev
developer
Ulvi IsmayilzadaLead
data
Fagan Feyzili
developer