Forem: Mohammed Ansari

From Chaos to Control: Building a Google Maps–Style AI Command Console with Cloud Run

Mohammed Ansari — Mon, 20 Apr 2026 15:34:38 +0000

How I went from a broken UI and failing deployments to a fully functional AI-powered stadium navigation system running on Google Cloud.

The Idea

What if a stadium dashboard behaved like Google Maps + Iron Man HUD + AI brain?

Not just static dashboards… but:

Real-time navigation
AI decision engine
Live crowd intelligence
Fully deployed on cloud

That’s exactly what I built.

The System Overview

This is not just a frontend project. It’s a full-stack AI system:

Architecture
User Input → Frontend (React)
→ Backend (Node.js)
→ BigQuery (crowd data)
→ Vertex AI (reasoning)
→ Firebase (logging)
→ Response → UI visualization

Tech Stack
Frontend: React + Vite
Backend: Node.js + Express
AI Layer: Vertex AI (Gemini)
Data Layer: BigQuery
Logging: Firebase
Deployment: Cloud Run
Infra: Docker + Artifact Registry

The UI: Not Just a Dashboard

I rebuilt the UI completely into a spatial AI control hub:

Key Features
Zoomable + pannable SVG map
Stadium zones (Gates, Facilities)
Animated AI route (particle flow)
Heatmap layer (crowd density)
Toggle-based facility layers
AI reasoning panel (typing effect)

The Real Challenge (Not UI… Logic)

At first, the system looked good but failed logically:

“I am at West Gate, where is medical station”
→ Returned random output

Root Problem:
No proper intent mapping
No structured routing logic
Fix: Deterministic Routing Engine

I introduced 3 layers:

Intent Normalization
"med station" → "Med Station"
"hungry" → "Food Stall"

Rule-Based Routing
Find nearest valid node
Use graph-based shortest path

Validation Guard
If no location → ask user instead of breaking

The REAL Battle: Cloud Run Deployment

This is where things went from “works locally” → “fails miserably”

Problem #1: Container Not Starting

Error:

“Container failed to start and listen on PORT=8080”

Why?

Cloud Run requires:

A running server
Listening on PORT env variable
Bound to 0.0.0.0
Fix (Backend)
const PORT = process.env.PORT || 8080;

app.listen(PORT, '0.0.0.0', () => {
console.log(Server running on ${PORT});
});

Problem #2: Frontend Fails on Cloud Run

Frontend = static files
Cloud Run = expects a server

Result → deployment failure

Fix (Frontend Server)

I had to wrap frontend inside a server

Docker: The Backbone

Backend Dockerfile:

FROM node:18

WORKDIR /app

COPY package*.json ./
RUN npm install

COPY . .

EXPOSE 8080

CMD ["node", "server.js"]

Final Result:
Backend running on Cloud Run
Frontend deployed on Cloud Run
AI routing working
UI stable (mostly 😅)
Full Google Cloud integration

Key Learnings

Cloud Run is simple… but strict

You must follow:
PORT
Server process
Correct container structure

Frontend ≠ static anymore in Cloud Run

You need:
Build → Serve → Run

AI ≠ just calling LLM
Without structure:
It fails badly
Debugging > Coding
Most time went into:
fixing deployment not building features

What I’d Improve Next
Better AI intent detection
Cleaner UI layout (no overlap)
Real-time streaming data
Graph-based routing engine upgrade

Final Thought

This project started as:

“Let’s build a cool UI”

It ended as:

“Let’s build a real production AI system”

Try It Yourself: https://stadium-frontend-986344078772.asia-south1.run.app/

Conclusion

If you’re building AI apps today:

Deployment is NOT optional
Architecture matters more than UI
Cloud knowledge = unfair advantage

Let’s Connect

If you're working on:

AI apps
Cloud deployments
Automation systems

Drop a comment or connect with me.

Prompt Wars Attempt 2 – From AI Demo to Real System

Mohammed Ansari — Mon, 20 Apr 2026 02:32:50 +0000

In my first attempt at Prompt Wars, I built a working AI solution.
It was functional. It responded correctly. But it didn’t feel like a real system.
That was the biggest lesson.
So for my second attempt, I changed my approach completely.
The system combines deterministic decision logic with AI reasoning, ensuring reliable outputs without hallucination.

The Shift in Thinking
Instead of asking: “How do I build this feature?”
I started asking: “How would this work in a real production system?”
That one change made everything different.

What I Built
I created an enhanced version of:
Smart Stadium AI Assistant
The goal:
• Reduce crowd congestion
• Help users navigate efficiently
• Provide real-time intelligent suggestions
But this time, the focus was not just output…
It was decision-making.

Core Architecture
I designed the system with clear layers:
User Input
→ Context Builder
→ Real-time Data (Firebase pattern)
→ Historical Data (BigQuery pattern)
→ Decision Engine
→ Vertex AI (reasoning)
→ Final Response
Each component has a role.
This made the system structured and scalable.

Tech Stack

Frontend
HTML5, CSS3 (Glassmorphism UI)
Vanilla JavaScript (no heavy frameworks)
Custom SVG for stadium visualization

Backend
Node.js
Express.js

AI & Decision Layer
Rule-based Decision Engine (custom logic)
Vertex AI (intent classification + reasoning)

Data & Simulation
Firebase (simulated real-time crowd data)
BigQuery (simulated historical analytics)

Deployment
Google Cloud Run (containerized Node.js service)
Google Cloud Build (image build & deployment)

Key Improvements Over Attempt 1

Decision Engine (Game Changer)
Instead of directly generating responses, I added a decision layer.
• Rule-based logic (shortest vs least crowded)
• Priority handling (normal vs high congestion)
• Fallback logic for edge cases
This ensured:
The system decides first, then responds
Real-time + Historical Intelligence
I simulated Google Cloud patterns:
• Firebase → live crowd data
• BigQuery → historical trends
• Vertex AI → reasoning
Now decisions are based on:
current situation + past patterns
Smarter Responses
Responses are no longer generic.
Example:
Recommended: Food Stall 2 (East Gate)
Crowd: Low (12%)
Reason: Nearby stall has 78% congestion
Alternative: Food Stall 1 (closer but high wait time)
This adds:
• clarity
• trust
• intelligence
Edge Case Handling
Real systems don’t break under pressure.
So I handled:
• Extreme crowd spikes (>85%)
• Empty stadium scenarios
• Invalid user inputs
The system adapts instead of failing.
Clean & Modular Code
Instead of one big file, I structured it as:
/engine → logic (context, decision, simulation)
/services → integrations (Firebase, BigQuery, Vertex AI)
/routes → API handling
/public → frontend
This improves:
• readability
• maintainability
• scalability

Deployment
I deployed the application using Google Cloud Run.
Why Cloud Run?
• Stateless architecture
• Auto-scaling
• Simple deployment
This made the system closer to a real-world setup.

Live App:https://smart-stadium-ai-986344078772.asia-south1.run.app/

Biggest Learning
My first version was:
“An AI that answers questions”
This version became:
“A system that makes decisions”
That is a huge difference.

What Could Be Better
• UI can be improved (more realistic map experience)
• More real integrations instead of simulated patterns
• Better performance optimization
But the foundation is now strong.

Final Thoughts
If you are building AI projects, don’t stop at:
• generating responses
• connecting APIs
Focus on:
How decisions are made
That’s what separates:
• demos
from
• real systems

Thanks for reading
If you have suggestions or feedback, feel free to share.
Always learning, always building

AI #GenAI #SystemDesign #GoogleCloud #CloudRun #PromptEngineering #LearningInPublic #BuildwithAI #PromptWarsVirtual

Building a Smart Stadium AI Assistant using Google Cloud (Without Overengineering)

Mohammed Ansari — Sun, 19 Apr 2026 17:24:54 +0000

This is my first blog, so keeping it simple and real.

Recently, I worked on a challenge where the goal was to improve the physical event experience in a large venue or a stadium.

Think about any big cricket match or football game or a Summit.

What usually happens?

Long queues at registration or food stalls
Confusion in finding exits
Crowd congestion near gates
No real-time visibility of what’s happening

So the question was:

Can we solve this using AI and cloud?

The Idea

Instead of building something overly complex, I focused on a practical system.

The goal was to simulate a smart assistant that can:

Guide users inside the venue/stadium
Suggest less crowded paths
Show real-time crowd density
Alert during sudden crowd spikes

Basically, make the experience smoother and stress-free.

Key Design Decision

Most people think:

AI = complex models + Python + training

But I took a different approach:

Simulated intelligence using real-time logic

Because in real-world systems:

speed matters
reliability matters
simplicity matters

System Architecture

I built a simple but effective architecture:

Frontend → shows venue/stadium layout and user interaction
Backend → handles simulation and logic
Simulation Engine → generates crowd movement and events
AI Layer → gives recommendations based on context

Everything works together like a mini real-world system.

Stadium Layout

I designed a structured stadium layout with:

4 Gates (North, South, East, West)
Parking Area
First Aid Center
Merchandise Store
Food Stalls (outside stadium area)
Fan Booth
Cab Pickup, Metro, Bus stations

All zones are connected with paths to simulate movement.

Tech Stack

Frontend: HTML, CSS, JavaScript
Backend: Node.js (Express)
Deployment: Google Cloud Run
Containerization: Docker (via Cloud Run)
Real-time Simulation: Custom event-driven logic

No heavy frameworks. No unnecessary dependencies.

Real-Time Simulation

The system simulates:

Crowd density across zones (%)
Gradual increase in crowd
Sudden spike when event ends
Empty stadium scenario

This makes the app feel “live” instead of static.

AI Routing Assistant

User can ask:

“I am at West Gate. Which is the nearest food stall?”

Instead of generic replies, the system responds like:

“The best option is Food Stall 2 towards South-East (near East Gate). It has low crowd (12%).”

This is based on:

current crowd data
zone positions
user intent

Security & Efficiency

Even though this is a demo, I added:

Input validation
Rate limiting
Secure headers

Also kept the repo:

Under 10 MB (very lightweight)

Deployment

Deployed using Google Cloud Run.

Why Cloud Run?

Easy deployment
Scales automatically
Works well with containerized apps

Live app: https://crowd-ctrl-app-986344078772.asia-south1.run.app

Challenges Faced

Some real issues I faced:

Serving frontend correctly in Cloud Run
Fixing API base URLs for production
Avoiding large repo size (node_modules issue)
Making UI clean without overloading it

Each of these taught something practical.

Key Learnings

This project changed how I think about AI systems.

You don’t always need complex AI models
System design matters more than tools
Simplicity + clarity = better results

And most importantly:

Don’t overengineer just to “look advanced” ;)

What I Would Improve Next

Add real Google Maps integration
Use actual real-time data from sensors
Improve route optimization logic
Add multilingual support

Final Thoughts

This was not just about building a Solution.

It was about:

thinking like a product builder
focusing on user experience
balancing simplicity and intelligence

If you are starting in AI or development:

Start building systems, not just models.

Thanks for reading 🙌
Would love to hear your thoughts or feedback!

AI #GoogleCloud #CloudRun #WebDevelopment #SystemDesign #LearningInPublic #BuildwithAI #PromptWarsVirtual