AI Enterprise SolutionsGPT & Claude

moveX

Who this is for:Daily Commuters (Baku & Suburbs): Students and office workers commuting daily from Sumgayit, Khirdalan, Masazir, and Absheron to Baku central hubs.AYNA & Bus Fleet Operators (Government / B2G): Transport authorities managing urban mobility and bus scheduling across the city network.Tourists & Occasional Travelers: Non-regular riders and visitors navigating Baku’s transit network without prior route experience.What goes wrong for them today:For Commuters & Travelers:Unpredictable Bus Crowding: Passengers have zero visibility into bus occupancy before arrival, leading to severe discomfort and unexpected boarding delays. Inefficient Route Decisions: Without real-time crowding forecasts, riders cannot decide whether to walk to a quieter stop, take an alternative route, or adjust departure times. For AYNA & Operators:Reactive Dispatching: Transport authorities only discover overcrowding after passenger complaints or severe delays occur, missing the window for proactive bus redistribution.

Open the demo Video GitHub

Preliminary score

73.0/ 100Strongaverage of 2 judges

Value for the user18.0 / 25
A specific problem and a clear outcome from solving it.
Prototype and use of AI22.5 / 30
A working core scenario, and what AI actually contributes to the result.
Quality testing17.0 / 20
Tests, examples of failures, and comparison with the current approach.
Feasibility9.5 / 15
Data requirements, running costs and a clear next step.
Originality6.0 / 10
A meaningful difference from common solutions.

What the judges wrote

Claude Opus 5.5Preliminary71/100
Strengths
Your prototype covers both sides of the problem: a live dispatch view where GPT-4o mini drafts per-route plans from weather, the holiday calendar and news, and a multilingual passenger assistant that uses tool calling to plan trips. Your testing is unusually honest and specific. It includes boundary tests on the crowd rule, prompt-injection attempts, AI latency figures, and real bugs you found and fixed (departures in the past, invalid times, a leaked API key). Your four-strategy benchmark openly reports that predictive dispatch removes severe crowding but costs about six times more bus-hours, which is the trade-off an operator actually needs to see.
To improve
All fleet, delay and crowd data is your own simulation, so every outcome number only holds inside your model. A pilot on even one real AYNA route, or historical delay data, would turn the claimed benefit into evidence. Your deck describes community crowd reports and passenger-flow data that the prototype does not have, and its TAM/SAM/SOM figures are inconsistent (SOM larger than TAM), so align the pitch with what you actually built. Add a concrete running-cost estimate (API calls per day, hosting at scale) and a cost-per-avoided-severe-minute figure, so the bus-hour trade-off becomes a decision AYNA can make.
GPT-6 AstraPreliminary75/100
Strengths
Your documented operator workflow combines live weather/news collection, AI-generated dispatch plans and human approval, with a linked passenger assistant. Your testing report covers boundary conditions, live-model latency and concrete failures such as impossible departure times and circular trips. You clearly disclose both the simulated nature of the results and the substantial extra bus-hours needed to achieve them.
To improve
Your next validation should compare actual passenger counts with GPS/delay data, because delay alone does not establish occupancy, and confirm AYNA's current workflow with operators. Compare your AI plan against a non-AI proactive baseline under the same fleet budget: your reported improvement uses 65–77 extra bus-hours versus 11 for reactive dispatch. Define a small operator pilot with a data-access plan, depot and driver constraints, and estimated AI and hosting costs.

The team

Isa Maharramov
developer
Nicat Bayramov/
developer
Huseyn AliyevLead
business

Disclosure

Required by the rules. Judges verify it against the repository.

Models: OpenAI GPT-4o mini (via API): writes the autonomous dispatch plans, runs the passenger trip assistant with tool calling, and answers in structured JSON. No other models are used in the product. During development we used AI coding help (Claude Code) and Gemini to draft the first prompt.
Data: Synthetic: the bus fleet, delays, crowd levels, city events and routes are simulated by our own model (no AYNA or partner data). Stop and venue locations are approximate real places in Baku. Public, collected live: Open-Meteo weather forecast, news headlines from Report.az, AZERTAC and Google News RSS, OpenStreetMap map tiles, and road geometry from the public OSRM server. The Azerbaijani holiday calendar was written by us.
Components: React 19 + Vite (create-vite starter template), Tailwind CSS, Leaflet / react-leaflet, lucide-react; Node.js + Express, built-in node:sqlite, OpenAI SDK, fast-xml-parser, dotenv, cors, concurrently; hosted on Render (free tier). No LangChain, no Supabase.
Built during the event: Confirmed

Quality testing

WHAT WE TESTED We wrote 26 automated tests (npm test), 10 live tests against the real AI model (npm run test:ai) and a simulation benchmark (npm run bench). They cover: the crowd rule at its boundaries (4.99 / 5 / 9.99 / 10 min), a full day of simulated delays with extreme fleet changes, the trip planner, bus timetables (checked against the moving buses), AI-plan timing, saved routines, and the API (bad input, oversized or hostile requests, rate limiting, key never leaked). We also tried prompt injection on the AI, in the pasted text and inside a fake news headline. A headless browser checked every screen for errors. AI answers were valid in 5 of 5 repeated runs; each AI call took 4.6 s (median) and 7.2 s (slowest). WHAT BROKE 1) A trip with a bus change could end at the stop it started from. 2) The AI plan told buses to leave in the past: with a real match headline it said "leave 14:25" at 15:30. 3) Times like 25:99 were accepted as valid. 4) Nothing stopped someone from spamming the AI on a public link and draining our budget. While building we also hit a white-screen crash, fake-looking AI percentages (every route -20 to -40%, same time for all routes) and an OpenAI key committed to git. All are fixed (key rotated, git history rewritten), and tests now guard each one. STILL WEAK The bus data is our own simulation, not real AYNA data. Predictive dispatch uses many more buses than reacting later. Prompt injection was tried only once in each of two places. We did not test real phones, other browsers or many users at once. News feeds are noisy (one irrelevant Formula 1 headline passed our filter, and the AI ignored it). COMPARED WITH HOW IT IS DONE TODAY Today dispatch follows fixed timetables and is adjusted after crowding is reported, and passengers use map apps that do not show crowding. We simulated an evening with three city events under four strategies: - No early action: 70 severe stop-minutes, peak delay 16 min, 0 extra bus-hours. - Reactive dispatcher (+2 buses 30 min after a stop turns severe): 65 severe stop-minutes, peak delay 16 min, 11 extra bus-hours. The surge is over before the buses arrive. - MoveX predictive plan: 0 severe stop-minutes, peak delay 7 min, 65 to 77 extra bus-hours. Planning ahead removes severe crowding in our model, but costs about six times more extra bus-hours. This comparison only holds inside our own simulation. Before you submit: - Repo link: if the form has a place for it, point to TESTING.md in the repo for the full report. Push the code first (git add -A, git commit -m "tests and fixes", git push), because it isn't on GitHub yet. - "Today" description: the line about how AYNA works today is my understanding. Change it if you know their real process.

Worth 20 of the 100 points.

Running it

Fastest way (no setup): open https://movex-ayna.onrender.com/. No login or credentials needed. The first load can take 30–60 seconds because the free server sleeps when idle; wait for it to wake, then refresh once if the map is empty. Quick tour: click the yellow Demo story button (top right). It walks through the whole product in 7 steps. Then try: - AYNA Dispatch → Operations: on the football match card press "Dispatch +2 Buses", and watch the red stops turn green. - AI Intelligence tab: press "Scan now". The server collects weather, calendar and news by itself and drafts a plan. Use the purple "Test" buttons to inject a storm or a road closure. Press "Deploy" on a route, or "Apply all remaining". - Passenger → Assistant: tap "Flag Square" or "Intervals of bus 125", or type where you want to go (English, Azerbaijani or Russian). - Passenger → My routine: press "Load demo", then tap a time chip like Mon 08:45 to preview a 30-minute-before reminder. Run it locally (Node.js 22.13 or newer): repo link: https://github.com/IsaMaharramov/moveX git clone https://github.com/IsaMaharramov/moveX.git cd moveX npm install Create a file named .env containing OPENAI_API_KEY=your_own_key. Then run npm run dev and open http://localhost:5173. Run the tests with npm test (no key needed), npm run test:ai (needs a key) and npm run bench. Known limitations: - Simulated fleet: the buses, delays and crowds are simulated, not AYNA data. Weather, news, the map and the AI are real. - Internet needed: the map, road routes, weather and news need an internet connection. - Free hosting: the server sleeps after about 15 minutes of no visitors, and it forgets server-saved routines when it restarts. Each browser keeps its own copy. - AI rate limit: the AI endpoints allow 20 requests per minute per visitor, so don't click "Scan now" in rapid bursts. - Routine reminders: they follow the simulated clock, so use the preview buttons. The simulated clock starts at 19:00 and runs fast.

Project ownership

The team keeps the rights to this project. Judges were given access for verification only.