Forem: Manjunath Patil

Google Cloud Next '26 Made One Thing Clear: Agents Need Infrastructure, Not Hype

Manjunath Patil — Thu, 30 Apr 2026 03:23:48 +0000

This is a submission for the Google Cloud NEXT Writing Challenge

Google Cloud Next '26 had a very loud headline: the agentic enterprise is here.

But the more interesting story, at least for developers, was quieter.

It was not just "agents are smarter now." It was this:

AI agents are finally being treated like production software.

That may sound less exciting than a keynote demo, but I think it is the real shift. The serious part of the event was not that an agent can answer a question, generate a document, or call an API. We have seen enough demos like that.

The serious part was Google saying, in many different ways, that agents now need infrastructure: runtime, identity, memory, observability, evaluation, access control, data grounding, secure sandboxes, and governance.

In other words, the future of agents is not just about better models. It is about everything around the model.

The announcement that stood out

The center of Google Cloud Next '26 was the new Gemini Enterprise Agent Platform.

Google described it as the evolution of Vertex AI: a platform to build, scale, govern, and optimize agents. That framing matters because it moves the conversation away from "Can I build a cool AI demo?" and toward "Can I run thousands of agents safely inside a real organization?"

Sundar Pichai's Next '26 post captured the shift well. He wrote that the question has moved from "Can we build an agent?" to "How do we manage thousands of them?" That one sentence explains most of the event.

Google's answer is a stack with pieces like:

Agent Development Kit, or ADK
Agent Studio
Agent Runtime
Agent Registry
Agent Identity
Agent Gateway
Agent Observability
Agent Simulation
Agent Evaluation
Memory Bank
Agent Sessions
Model Armor
Google Cloud MCP servers

That is a lot of product names. But under the naming, there is a real architecture forming.

The developer keynote made it real

The opening keynote gave the vision. The developer keynote made it practical.

The demo was built around planning a marathon in Las Vegas. That sounds like a toy problem until you think about what it actually requires: route planning, constraints, simulation, safety, logistics, evaluation, and constant iteration.

The system used multiple specialized agents instead of one giant "do everything" agent:

A planner agent proposed marathon routes.
An evaluator agent checked those routes against requirements.
A simulator agent modeled the impact on the city.
A supply chain agent handled logistics like water stations, medical tents, and portable toilets.

That is the architecture pattern I found most useful: not one magical assistant, but a network of smaller agents with clear jobs.

The developer keynote showed agents using ADK, MCP, Agent Runtime, Agent Registry, A2A-style agent communication, A2UI-style user interfaces, Memory Bank, runtime traces, Cloud Assist, Cloud Run, GKE, Agent Identity, and Agent Gateway.

That is much closer to real software engineering than the usual "I typed a prompt and magic happened" demo.

The hidden message: agents need boring systems

The most underrated part of Next '26 was how much of the agent story was boring in the best possible way.

Boring like logs.

Boring like identity.

Boring like access control.

Boring like knowing what changed, who changed it, what tool got called, what data was accessed, and why the agent made a bad decision.

That is what makes software production-grade.

A chatbot can be loose. A production agent cannot.

If an agent can read documents, write code, trigger workflows, browse internal systems, call another agent, or act on customer data, then it needs the same discipline we expect from any other production system.

That is why features like Agent Identity and Agent Gateway matter. Agent Identity gives agents a trackable identity. Agent Gateway becomes a control point for agent-to-agent and agent-to-tool traffic. Agent Registry gives organizations a way to know what agents and tools exist. Agent Observability gives developers traces and logs for debugging.

This is not glamorous, but it is the difference between "cool demo" and "I would trust this in production."

What people seem excited about

After reading the official announcements and community reactions, the excitement is mostly around practical developer workflows.

ADK is a big one. Developers want a way to build multi-agent systems without inventing the architecture from scratch. Google's graph-based ADK direction is interesting because it acknowledges that agent workflows need structure. Some tasks can be generative, but some need deterministic paths, especially in compliance, security, finance, healthcare, and operations.

MCP is another major theme. Google is exposing cloud services through Model Context Protocol and also announced an official Agent Skills repository. I like this because it tackles a problem developers already feel: context bloat. Giving an agent the entire internet, all docs, and every internal page is not a strategy. Smaller, task-specific skills are a cleaner way to give agents expertise only when needed.

Cloud Run updates also caught attention. Developers care about things like managed MCP servers, long-running background agents, sandboxing, SSH support, service bindings, serverless GPUs, and billing caps. Billing caps may not sound like a keynote-worthy feature, but for developers worried about surprise cloud bills, that can be more exciting than another model benchmark.

There was also interest in the codelabs. Google said there were 55+ new codelabs across Cloud at Next, with labs covering ADK + A2UI, multi-agent systems, secure agents, Google Maps grounding, Agent Engine deployment, Cloud Run, and agent skills. That matters because developers do not just need a keynote. They need something they can run after the keynote ends.

What people are worried about

The concern I saw again and again is AI fatigue.

Some developers are asking whether Google Cloud Next is becoming "Gemini Next." On Reddit, one person joked about trying to find a session without AI and failing. Another pre-event thread asked what people expected besides "Agentic AI spam."

That frustration is fair.

A lot of production teams still care about IAM, networking, Kubernetes, databases, cost controls, observability, migrations, and reliability. If every topic gets wrapped in "agentic AI" language, it can start to feel like the practical infrastructure concerns are being painted over with marketing.

But I think the best version of Google's Next '26 story actually answers that criticism.

The useful announcements were not "AI will fix everything." The useful announcements were about the infrastructure agents need when they stop being demos:

GKE Agent Sandbox for isolated execution
Agent Runtime for deployment
Agent Gateway for governed traffic
Agent Identity for traceable permissions
Agent Observability for debugging
Agent Evaluation for quality checks
Model Armor for prompt injection and data leakage protection
Knowledge Catalog for trusted business context
Cloud Run billing caps for cost safety

Those are not just AI features. They are operational features.

The data story may be more important than the model story

Google also announced the Agentic Data Cloud, and I think this might be one of the most important parts of the event.

Agents are only useful if they understand the business context around the task.

A generic model may understand the word "margin," but inside a company, "margin" might depend on team-specific definitions, regional rules, product lines, internal dashboards, and messy historical decisions. If an agent does not understand that context, it will confidently do the wrong thing.

That is why Knowledge Catalog, Cross-Cloud Lakehouse, BigQuery measures, LookML Agent, Data Agent Kit, and Conversational Analytics matter. They are not just data products. They are attempts to make enterprise context usable by agents.

This is where the agentic enterprise either becomes real or falls apart.

Without trusted context, agents hallucinate.

Without permissions, agents leak data.

Without observability, agents become impossible to debug.

Without evaluation, agents drift.

Without cost controls, agents become expensive experiments.

Security is not optional anymore

The security announcements also stood out. Google is combining Google Threat Intelligence, Security Operations, and Wiz into what it calls Agentic Defense.

The important idea here is that agents create new attack surfaces.

If agents can use tools, attackers will try to poison tools.

If agents can read data, attackers will try to extract data.

If agents can call other agents, attackers will try to exploit the chain.

If agents can execute code, attackers will try to turn them into execution paths.

This is why Agent Identity, Agent Gateway, Model Armor, Wiz, threat detection agents, detection engineering agents, and runtime security all belong in the same conversation as ADK.

Security cannot be a final checklist after the agent is built. It has to be part of the agent architecture.

My honest take

I am excited, but cautiously.

I like that Google is treating agents as systems, not toys. The developer keynote was strongest when it showed the full lifecycle: build, test, remember, debug, deploy, scale, and secure.

That is the right framing.

But I also think the industry needs to be careful. "Agentic" is becoming a word that gets attached to everything. Not every workflow needs an autonomous agent. Some need a form. Some need a queue. Some need a cron job. Some need a dashboard. Some need better documentation.

The best agent systems will not be the ones that automate the most. They will be the ones that know when to act, when to ask, when to stop, and when to hand control back to a human.

That is why the boring parts matter so much.

The future is not one giant AI agent running a company. The future is probably many small, specialized agents operating inside strict boundaries, with humans still setting intent, reviewing important decisions, and owning the outcome.

Final thought

Google Cloud Next '26 made one thing clear to me:

The agent era will not be won by the flashiest chatbot.

It will be won by the platform that makes agents observable, governable, secure, grounded in real data, and boring enough to trust.

That is a less dramatic story than "AI will do everything."

But for developers, it is a much better one.

Because if agents are going to become part of real software, they need to behave like real software.

And real software needs infrastructure.

Earth Day Study Companion: For Teach-Ins and Climate Learning

Manjunath Patil — Mon, 20 Apr 2026 06:54:44 +0000

This is a submission for Weekend Challenge: Earth Day Edition

What I Built

I built Earth Day Study Companion, a climate learning workspace designed to help people move from reading, to understanding, to teaching, to action.

The idea came from a simple problem. A lot of Earth Day and climate learning happens in fragments. Someone reads a long PDF report, watches a few videos, collects some slides, saves a few articles, and then tries to turn all of that into a class, a club session, a workshop, or a community discussion. The information exists, but the workflow is messy. Research is disconnected from teaching. Planning is disconnected from delivery. Good material is often trapped inside dense documents that are hard to search and even harder to teach from.

I wanted to build a product that makes that process feel connected from start to finish.

Earth Day Study Companion has three core experiences: Climate Library, Teach-In Builder, and Teach-In Facilitator.

Climate Library is the research layer. Users can upload climate reports, sustainability guides, Earth Day toolkits, policy PDFs, and other learning material. The system stores the documents, processes them, chunks them into smaller pieces, creates embeddings, and uses retrieval before answering questions. That means the experience is not just a generic chatbot on top of a file upload. It is a grounded document assistant built on top of retrieval augmented generation. Users can ask questions about what is inside the document, open the relevant page, and jump back to the exact source material that informed the answer. This is especially useful for long climate documents where the user needs clarity, context, and source confidence.

The library also becomes more useful because it is connected to live multimodal interaction. A user can turn on the microphone and ask questions naturally. They can also share the screen and ask if a chart, image, article, PDF section, or slide is worth using. This matters in real Earth Day preparation because people do not only work with text. They work with visual material, reports, and presentation content. The screen share helps Gemini reason over what is visible, so the user can ask practical questions like whether a page is relevant, whether a graph is clear enough, or whether a specific visual should be included in a session.

Teach-In Builder is the structure layer. Once the user knows the topic they want to teach, the Builder turns that topic into a learning pathway. Instead of producing only a plain outline, the system creates both a pathway view and a mind map. The pathway helps with order and progression. The mind map helps with relationships and scope. This makes it easier to take a broad subject like renewable energy, climate justice, biodiversity, food systems, or circular economy and turn it into something teachable.

Each generated module can then be expanded into Guide, Practice Lab, and Field Media. The Guide is for explanation and learning flow. Practice Lab helps turn passive reading into active thinking. Field Media connects the topic to supporting examples and related material. I wanted the Builder to feel like a real educational workspace, not a one shot prompt output. The result is something that can help a student explore a topic, but it can also help a facilitator or organizer design a real Earth Day learning session.

Teach-In Facilitator is the planning layer. This is where the project moves from learning support into real event preparation. The user starts by filling in a session brief with the audience, venue or context, title, duration, goals, focus areas, and available materials. From there, Gemini acts like a live planning partner. The user can talk through the idea naturally, refine the session structure, and decide how the event should feel for that specific audience.

This is also where the live controls become very important. The microphone supports a natural planning conversation. Screen share allows the facilitator to show slides, PDFs, webpages, images, and other planning material while asking Gemini for feedback. The webcam adds live visual context during the planning session. In practice, this makes the product feel much closer to a real coaching partner than a standard prompt box. A user can ask if a resource looks relevant, if a visual seems clear, or if a piece of material fits the tone of the session they are planning.

As the session develops, the app turns that planning process into a structured output with a summary, learning objectives, agenda, materials, and community actions. At the end, the system generates a facilitator report as a downloadable PDF. That final step is important because it turns a live planning session into something reusable. The user leaves with a practical artifact they can actually use for a school club, a local workshop, a library event, or a community Earth Day gathering.

My intended goal with this project was to build something that feels genuinely useful for Earth Day. Not just a climate themed UI, not just an AI wrapper, and not just a static educational demo. I wanted to build a tool that helps people understand climate material, turn it into a teaching structure, and prepare a real session around it.

Demo

Live demo: https://earthdaycompanion.vercel.app/

Video demo: https://youtu.be/V-v_MHj3HJw

In the demo, I walk through the product as a full learning and planning flow.

I start inside Climate Library by uploading a climate related PDF and asking questions about it. This shows how the system indexes the document, retrieves relevant chunks, and answers in a way that stays tied to the uploaded material. I also show page level navigation and jumping back to the relevant part of the PDF, because that is one of the most important parts of the library experience. I wanted viewers to see that the system is not guessing. It is actually working with the document.

Then I move into Teach-In Builder and generate a structured pathway on an Earth Day topic. I show the pathway view and the mind map view, then open a module to show how the Guide, Practice Lab, and Field Media sections work. This part demonstrates how the product turns a broad environmental topic into a teachable sequence instead of only summarizing it.

Finally, I open Teach-In Facilitator and show how the app can be used as a live planning partner for a real Earth Day session. I walk through the brief, start the live flow, and show how Gemini helps shape the structure of the teach-in. I also show how screen sharing can be used to review materials visually during the planning process. At the end, I generate the facilitator report PDF to show how the live planning flow becomes something concrete and reusable.

Screenshots

This is the landing experience, where the product introduces the three connected flows: Climate Library, Teach-In Builder, and Teach-In Facilitator.

This is the Climate Library, where uploaded PDFs become grounded, searchable learning material.

This is the Teach-In Builder, where a broad Earth Day topic becomes a pathway and a mind map.

This is the Teach-In Facilitator, where Gemini helps shape a real session and generate a usable report.

Code

GitHub repository: https://github.com/ladiesmans217/Earth-Day-Challenge

The project is built with a React and TypeScript frontend and a Python backend. The frontend handles the user experience across the three main flows, while the backend handles document processing, retrieval, generation, and report output.

On the document side, the backend stores uploaded PDFs, chunks the content, creates embeddings, and uses ChromaDB for retrieval. On the live interaction side, Gemini powers the voice based multimodal experience. On the planning side, Gemini function calling is used to create a structured teach-in plan. On the output side, the backend generates a facilitator report PDF so the planning session ends with a practical result.

Code Snippets

This snippet shows how PDF pages are chunked and indexed into ChromaDB for grounded retrieval.

def ingest_pdf(self, pdf_path: str) -> Dict:
    if not os.path.exists(pdf_path):
        return {"status": "error", "message": f"PDF not found: {pdf_path}"}

    pages = self.extract_text_from_pdf(pdf_path)
    if not pages:
        return {"status": "error", "message": "Failed to extract text from PDF"}

    filename = os.path.basename(pdf_path)
    added_count = 0

    for page in pages:
        chunks = self.chunk_text(page['text'])

        for chunk_idx, chunk in enumerate(chunks):
            if len(chunk.strip()) < 10:
                continue

            chunk_id = hashlib.md5(
                f"{filename}_{page['page_num']}_{chunk_idx}".encode()
            ).hexdigest()

            self.collection.add(
                ids=[chunk_id],
                documents=[chunk],
                metadatas=[{
                    "source": filename,
                    "page_num": page['page_num'],
                    "chunk_idx": chunk_idx,
                    "full_path": page['path'],
                    "ingested_at": datetime.now().isoformat()
                }]
            )
            added_count += 1

    return {
        "status": "success",
        "filename": filename,
        "pages": len(pages),
        "chunks_added": added_count
    }

This snippet shows part of the Climate Library viewer logic, including the local PDF worker and the in-memory PDF cache used to keep the viewer responsive.

pdfjs.GlobalWorkerOptions.workerSrc = `${process.env.PUBLIC_URL || ""}/pdf.worker.min.js`;

type CachedPdf = {
  blob: Blob;
  objectUrl: string;
  totalPages: number;
  pageTextByPage: Record<number, string>;
  pdfDocument: any;
};

const pdfCacheRef = useRef<Map<string, CachedPdf>>(new Map());

const getPdfCacheKey = useCallback((file: File) => {
  return normalizePdfName(file.name);
}, []);

This snippet shows the default Teach-In Facilitator brief and how the experience starts with a strong session setup instead of a blank form.

export const DEFAULT_TEACH_IN_BRIEF: TeachInBrief = {
  sessionTitle: "Neighborhood Clean Energy Teach-In",
  audience:
    "High-school students, parents, and community volunteers curious about practical local climate action",
  venueContext:
    "Public library community room with projector and open discussion seating",
  duration: "45 minutes",
  goals:
    "Help attendees understand clean energy in everyday life, connect it to climate justice, and leave with two realistic actions they can take this month.",
  focusAreas:
    "Renewable energy basics, energy bills, climate justice, neighborhood resilience, community action",
  materials:
    "Projector, whiteboard, local utility bill example, sticky notes, Earth Day handout, signup sheet",
};

How I Built It

I built the product around a three step model: study, structure, and facilitate.

For the study layer, the main focus was grounding. Climate material is often long, technical, and dense, so I did not want a system that simply accepted a PDF and then answered in a vague way. When a user uploads a document into Climate Library, the backend stores the file, extracts the text, splits it into chunks, creates embeddings, and stores them in ChromaDB. When the user asks a question, the backend retrieves the most relevant chunks and passes them into the model as context. That creates a proper retrieval augmented generation flow instead of a general chat flow. It also allows the app to support citations, page navigation, and highlighted source jumps back into the document.

That source connection was important to me because climate literacy is not only about getting an answer. It is about trusting where the answer came from. If someone is preparing an Earth Day session, a school lesson, or a community discussion, they need to be able to go back to the original material and verify what they are using.

For the structure layer, I wanted to go beyond a single generated course outline. That is why Teach-In Builder creates both a pathway and a mind map. Those two views do slightly different jobs. The pathway helps the user think in sequence, while the mind map helps the user think in connections. Once a module is opened, the system expands it into Guide, Practice Lab, and Field Media so the topic becomes something a person can actually work through and teach from. This part of the build was about making generated content feel usable, not just impressive.

For the facilitate layer, I adapted the live assistant flow into a planning companion for real Earth Day events. The user starts with a structured brief, then moves into a live Gemini session where the focus is on audience fit, session flow, materials, and next steps. Function calling is used to turn that planning flow into a structured output with learning objectives, agenda, materials, and community actions. I wanted this to feel like an event planning tool, not a generic live chat demo.

Gemini is the key technology across the whole project. I used it for live voice interaction, multimodal context, structured teach-in planning, and document assistance when paired with retrieval. In Climate Library, Gemini helps turn indexed PDFs into an interactive learning experience. In Teach-In Builder, it supports turning broad topics into structured educational pathways. In Teach-In Facilitator, it helps shape a real Earth Day session that can actually be delivered to an audience.

The shared live control tray also became a meaningful part of the product. The microphone supports a more natural planning and exploration flow. Screen share makes the assistant useful for real materials, not just typed prompts. Webcam adds live visual context to the session. Together, those controls make the app feel more like a working multimodal study and facilitation environment.

I also spent time on the interface direction because I did not want the project to feel like a generic AI dashboard. I moved away from a loud or overly synthetic look and shaped it into something more like an editorial field guide for climate learning. The goal was to make the experience feel grounded, readable, and specific to Earth Day rather than looking like a general purpose AI tool with green branding.

The biggest thing I learned while building this was that climate education is a strong and practical Earth Day direction. Many projects in this space focus only on tracking or visualization. Those are useful, but I wanted to build around the human part of environmental action: understanding the material, organizing it, and helping other people learn from it. That is where I think this project is strongest.

Prize Categories

I am submitting this project for Best Use of Google Gemini.

Gemini is central to the project, not an extra layer added on top. It powers the live voice interaction, the multimodal reasoning over shared visual context, the structured teach-in planning flow, and the grounded assistance in the document workflow when combined with retrieval.

This is a solo submission.

TerraRun — A Territory Capture Running App Where Every Loop You Run Becomes Your Turf

Manjunath Patil — Mon, 02 Mar 2026 07:58:17 +0000

I'm part of the running community — people who lace up every morning, track every mile, and obsess over their Strava stats. Running apps today are incredible at what they do. Strava tracks your routes. Nike Run Club coaches your training. MapMyRun logs your history.

But here's the gap I kept noticing: once you finish a run, what do you actually own? A line on a map and some numbers. There's no lasting mark on the world. No reason to go back to the same streets, no incentive to explore new ones, and no connection between your physical effort and the neighborhoods you run through every day.

Runners already feel ownership over their routes — "that's MY morning loop" — but nothing on the map reflects that. I wanted to change that.

What I Built

TerraRun — a territory capture running app where every closed loop you run becomes your turf on the map.

The concept: go for a run, close a loop (your route connects back to where you started), and the enclosed area fills in with your color on a shared public map. That's your territory now. Other runners can reclaim it by running the same loop. The more territory you hold, the higher you rank.

Think of it as Strava meets king-of-the-hill — your runs aren't just logged, they're staked.

Key features:

Territory Capture — Run a closed loop, and the exact shape of your route becomes claimed territory on the map. Not a grid, not circles — the actual polygon of your run, just like Strava route art.
Live Run Simulation — A "Watch Demo Run" button animates a runner tracing an irregular street-level route in real-time. When the loop closes, the territory fills in with a capture animation.
Share Card — After capturing territory, a share modal pops up with your route shape rendered as a graphic, plus your stats (distance, time, pace, area). One tap to share on WhatsApp, Telegram, X, or copy the link.
Interactive Map — Full-screen Mapbox map with 4 styles (Dark, Streets, Satellite, Outdoors), 3D toggle, territory click popups showing owner and capture date.
Leaderboard — Runners ranked by territory held. Top 3 podium. Filters for All Time, This Week, Nearby.
Profile Dashboard — Your stats, achievement badges, active streak, and activity feed.
Sponsor Zones — Brands (Nike, Adidas, Gatorade, Under Armour) place zones on the map. Run through them to unlock real coupon codes. Runners get rewarded. Brands get literal foot traffic.

What makes this different from existing apps:

	Strava	Nike Run Club	TerraRun
Tracks runs	✅	✅	✅
Social competition	Segments only	Challenges	Territory wars
Map ownership	❌	❌	Your runs claim real map area
Reason to re-run a route	❌	❌	Defend your territory
Brand engagement	Ads	Ads	Physical sponsor zones you run to

Demo

YOUTUBE VIDEO LINK

Live deployment: TerraRun on Vercel

Code

manjunath5513 / Dev-Challenge

TerraRun — Run. Loop. Conquer.

A territory capture running app where every closed loop you run becomes your turf on the map. Built for the DEV Weekend Challenge (Feb 27 – Mar 2, 2026).

Live Demo: terrarun-dev.vercel.app

Video Demo: youtu.be/Cr7n3qfzARM

The Idea

Running apps like Strava and Nike Run Club are great at tracking — but once a run is done, all you have is a line on a map. TerraRun changes that. Run a closed loop, and the enclosed area fills in as your territory. Others can reclaim it by running the same loop. Every neighborhood becomes a game board.

Features

Territory Capture — Closed-loop runs become filled polygon territories on the map, matching the exact shape of your route
Live Run Simulation — Animated demo run traces an irregular street-level path, captures territory on loop close
Share Card — Post-capture modal with route shape graphic, stats (distance, time…

View on GitHub

Project structure:

terrarun/
├── src/
│   ├── app/                    # Next.js App Router pages
│   │   ├── page.tsx            # Landing page
│   │   ├── map/page.tsx        # Main interactive map
│   │   ├── leaderboard/page.tsx
│   │   ├── profile/page.tsx
│   │   └── sponsors/page.tsx
│   ├── components/
│   │   ├── map/                # MapView, TerritoryLayer, RunSimulation, ShareModal
│   │   ├── landing/            # Hero, Features, HowItWorks
│   │   ├── layout/             # Navbar with mobile bottom nav
│   │   ├── leaderboard/        # LeaderboardTable
│   │   └── profile/            # ProfileStats
│   ├── lib/
│   │   ├── mock-data.ts        # 6 users, 7 territories, 4 sponsors
│   │   ├── territory.ts        # Polygon territory generation with Turf.js
│   │   ├── h3-utils.ts         # H3 hex utilities (available for future use)
│   │   └── constants.ts        # Map config, styles, colors
│   ├── store/
│   │   └── useMapStore.ts      # Zustand state management
│   └── types/
│       └── index.ts            # TypeScript interfaces

How I Built It

Tech Stack

Technology	Purpose
Next.js 16	Framework — App Router, SSR, file-based routing
React 19	UI rendering
TypeScript	Type safety across the entire codebase
Tailwind CSS 4	Styling — dark theme, glass morphism effects
Mapbox GL JS 3 + react-map-gl 8	Interactive map rendering with 4 style modes
Turf.js 7	Geospatial calculations — polygon area from GPS coordinates
Framer Motion 12	Animations — page transitions, capture celebrations, share modal
Zustand 5	Lightweight state management for map and simulation state
Lucide React	Icon system

How the territory system works

The core mechanic: a runner's GPS route forms a closed polygon. When the loop closes, I use Turf.js to calculate the enclosed area in km², and render it as a filled GeoJSON polygon on the Mapbox map. The territory is the exact shape of the run — no grids, no approximations.

// Convert route points to a territory polygon
const ring = routePoints.map(p => [p.lng, p.lat]);
const poly = turfPolygon([ring]);
const areaKm2 = turfArea(poly) / 1_000_000;

Each territory stores: polygon coordinates, owner, color, area, capture date. Territories are rendered as GeoJSON with a 3-layer glow border effect (outer blur + mid blur + core line) for that neon territory look.

The run simulation

The demo run isn't a perfect circle — it's an irregular street-level route that zigzags through Central Park paths, because that's how real runs look. The animation:

Runner marker moves along the route at running pace
A trail polyline draws behind in real-time
When the loop closes → territory fill animation + capture stats
Share card appears with the route shape, stats, and social share buttons

Design decisions

Polygons over hex grids — I initially built with H3 hexagons but realized runners follow streets, not grids. Polygon fills matching the actual run shape feel natural and look like the Strava route screenshots people already share.
Dark theme default — Territory colors glow best on dark backgrounds. The glass morphism UI keeps it clean.
Mobile-first — Bottom navigation bar, touch-friendly controls, responsive everything. Runners use phones.
Share-first capture flow — The share modal appears immediately after capture because the screenshot moment is what drives virality in running apps.

Built in a weekend

This was built from scratch during the DEV Weekend Challenge window. The entire app — 5 pages, interactive map, run simulation, territory system, share flow — was designed, coded, and deployed within the challenge timeframe.

AI was used as a development tool throughout the process.

Run. Loop. Conquer. 🏃

I Built a GeoGuessr for Languages — Here's How I Made It Speak 8 Languages Overnight

Manjunath Patil — Mon, 23 Feb 2026 18:29:06 +0000

I've sunk embarrassing hours into GeoGuessr. There's something deeply satisfying about squinting at a road sign in Cyrillic, spotting a right-hand-drive car, and triumphantly dropping a pin somewhere in rural Bulgaria. One evening, while half-listening to a Turkish podcast I didn't understand, it clicked — what if the clue wasn't a photo of a street, but the sound of a language?

Think about it. You hear someone speaking. The rhythm, the vowels, the melody of the sentence. Can you tell Japanese from Korean? Portuguese from Spanish? Hindi from Urdu? That question became LinguaGuessr — a game where you listen to a language, pin its origin on a world map, and get scored by how close you land.

This is the story of how I built it, the tech decisions that shaped it, and how I made the entire UI speak 8 languages overnight — using Lingo.dev.

The problem: language learning is boring, and i18n is painful

Let's be honest — most language learning apps are glorified flashcard decks. Duolingo gamified vocabulary drills, but the core loop is still memorize → recall → repeat. GeoGuessr proved that geography can become a game people play for fun, not obligation. Why hasn't anyone done that for linguistics?

I wanted to build something where you experience languages rather than study them. Hear a clip, feel the rhythm, take a guess, learn a fun fact. No textbooks, no streaks, no guilt.

But there was a second problem lurking underneath: if you're building a game about languages for a global audience, the UI itself needs to speak the player's language. And anyone who's shipped i18n knows the pain — JSON key files, missing translations, string interpolation bugs, a whole parallel codebase just for text. Building a game is hard enough. Making it multilingual felt like signing up for two projects.

What is LinguaGuessr?

The game loop is dead simple — three steps:

Listen — Hear a clip of someone speaking a mystery language
Pin — Click anywhere on the world map to place your guess
Score — The closer your pin to the language's true origin, the more points you earn (max 5,000 per round)

There are 125+ languages in the database — from the obvious (English, Spanish, Mandarin) to the obscure (Basque, Yoruba, Guarani, Corsican). Each language comes with geographic coordinates, a difficulty rating, and a fun cultural fact that shows up after you guess.

The game supports solo mode with a global leaderboard, and multiplayer mode where you create a room, share a code, and compete in real time. Five rounds per game, max 25,000 points, and bragging rights for whoever knows their Amharic from their Tigrinya.

Tech stack

Here's what powers LinguaGuessr under the hood:

Layer	Technology	Why
Framework	Next.js 16 (App Router)	Server components, API routes, fast builds
Styling	Tailwind CSS v4	Utility-first, dark theme, zero CSS files
Map	Leaflet + react-leaflet	Open-source, lightweight, great mobile support
Realtime	Supabase (Postgres + Realtime)	Room codes, presence, broadcast — all in one
i18n	Lingo.dev (Compiler + SDK + CLI + CI/CD)	Build-time JSX translation, runtime dynamic translation
Audio	Web Speech API	Zero-cost TTS with native browser voices
Language	TypeScript	Type safety across the entire stack

Every choice was deliberate — I wanted a stack that could ship fast, scale to multiplayer, and handle i18n without a separate translation infrastructure.

The game mechanics — under the hood

Audio: a three-tier fallback

Audio is the core mechanic. If the player can't hear the language, there's no game. So I built a three-tier fallback system:

MP3 files — Pre-recorded clips for supported languages
Web Speech API — Browser-native text-to-speech as a fallback (free, zero-cost, surprisingly good)
Text display — If both fail, show the phrase on screen and let the player guess from the script

// Try MP3 first, fall back to Web Speech API
if (audioUrl) {
  audioRef.current = new Audio(audioUrl);
  audioRef.current.onerror = () => {
    setUseWebSpeech(true);
    playWithWebSpeech();
  };
  audioRef.current.play().catch(() => {
    setUseWebSpeech(true);
    playWithWebSpeech();
  });
} else {
  playWithWebSpeech();
}

The Web Speech API is underrated. Every modern browser ships with dozens of language voices. It's not perfect — some voices sound robotic, and coverage varies by OS — but for a game where you just need to hear the language, it's more than enough. And the price is right: free.

Map: Leaflet with custom pins

The map uses Leaflet with OpenStreetMap tiles. When a player clicks, a gradient pin drops at their guess location. After scoring, a dashed line draws from their guess to the correct location, giving immediate visual feedback on how close (or far off) they were.

Scoring: Haversine formula + exponential decay

The scoring uses the Haversine formula to calculate the great-circle distance between the player's guess and the language's true origin. Then an exponential decay curve converts distance to points:

export function haversineDistance(
  lat1: number, lng1: number,
  lat2: number, lng2: number
): number {
  const R = 6371; // Earth's radius in km
  const dLat = toRad(lat2 - lat1);
  const dLng = toRad(lng2 - lng1);
  const a =
    Math.sin(dLat / 2) ** 2 +
    Math.cos(toRad(lat1)) * Math.cos(toRad(lat2)) *
    Math.sin(dLng / 2) ** 2;
  return R * 2 * Math.atan2(Math.sqrt(a), Math.sqrt(1 - a));
}

export function calculateScore(distanceKm: number): number {
  if (distanceKm <= 200) return 5000; // Perfect score
  // Exponential decay: forgiving but steep
  return Math.max(0, Math.round(5000 * Math.exp(-distanceKm / 3000)));
}

The curve is deliberately forgiving — you don't need to nail the exact country. Within 200km is a perfect 5,000. At 2,000km you still get ~2,500. But by 10,000km you're down to ~50 points. It rewards knowledge without punishing reasonable guesses.

Multiplayer with Supabase Realtime

I wanted multiplayer from day one. The idea of friends arguing about whether that clip was Finnish or Estonian is too good to skip.

Supabase Realtime made this surprisingly simple. The entire multiplayer system runs on presence tracking plus four broadcast events:

Event	Purpose
`presence:sync`	Track who's in the room
`game_start`	Host starts the game, sends the language list to all players
`guess_submitted`	A player submits their guess and score
`next_round`	Advance everyone to the next round
`game_finished`	Show final rankings

Here's the core channel setup:

const channel = supabase.channel(`room:${roomCode}`, {
  config: { presence: { key: player.name } },
});

channel
  .on("presence", { event: "sync" }, () => {
    const state = channel.presenceState();
    // Update player list from presence state
  })
  .on("broadcast", { event: "game_start" }, ({ payload }) => {
    setLanguages(payload.languages);
    setPhase("playing");
  })
  .on("broadcast", { event: "guess_submitted" }, ({ payload }) => {
    // Update scoreboard with player's round score
  })
  .on("broadcast", { event: "next_round" }, ({ payload }) => {
    setCurrentRound(payload.round);
    setPhase("playing");
  })
  .on("broadcast", { event: "game_finished" }, () => {
    setPhase("finished");
  })
  .subscribe();

The entire multiplayer flow — lobby, gameplay sync, scoreboard — is handled by these events. No custom WebSocket server, no socket.io, no polling. And if Supabase is unavailable? The game gracefully degrades to solo mode with in-memory scores.

Making it multilingual with Lingo.dev

Here's where it gets fun. I'm building a game about languages. The irony of shipping it in English-only was not lost on me. But I also knew from past projects that i18n is a time sink — extracting strings into JSON files, maintaining translation keys, wiring up a provider, hoping nothing breaks when a new string shows up.

Then I found Lingo.dev, and it changed my whole approach.

The Compiler: auto-translate JSX at build time

The Lingo.dev Compiler wraps your Next.js build and automatically translates all JSX text content. No string extraction. No JSON key files for your UI text. You write your components in English, and the compiler handles the rest.

The setup is minimal — just wrap your Next.js config:

// next.config.ts
import { withLingo } from "@lingo.dev/compiler/next";

const nextConfig: NextConfig = {
  images: { unoptimized: true },
};

export default async function (): Promise<NextConfig> {
  return await withLingo(nextConfig, {
    sourceLocale: "en",
    targetLocales: ["es", "fr", "de", "ja", "hi", "ar", "pt"],
    models: "lingo.dev",
  });
}

That's it. Seven target languages. Every <p>, <h1>, <button>, and <span> in my React components now gets translated at build time into Spanish, French, German, Japanese, Hindi, Arabic, and Portuguese. No t("key") calls. No intl.formatMessage. Just write English and ship globally.

The SDK: runtime translation for dynamic content

Static UI text is only half the story. LinguaGuessr has dynamic content — fun facts about each language that come from the database. These can't be translated at build time because they're loaded at runtime. The Lingo.dev SDK handles this:

import { LingoDotDevEngine } from "lingo.dev/sdk";

const engine = new LingoDotDevEngine({
  apiKey: process.env.LINGODODEV_API_KEY,
});

const translated = await engine.localizeText(funFact, {
  sourceLocale: "en",
  targetLocale: userLocale,
});

So when a Japanese-speaking player finishes a round, the fun fact about Basque being a language isolate shows up in Japanese. The static UI was already in Japanese from the compiler. The dynamic content gets translated on-the-fly by the SDK. The player sees a fully localized experience.

CI/CD: auto-translate on every push

For static locale files (language names, country names, error messages), I use the Lingo.dev CLI paired with a GitHub Action:

# .github/workflows/translate.yml
on:
  push:
    branches: [main]
    paths: ['src/locales/en.json', 'i18n.json']

jobs:
  translate:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Run Lingo.dev CLI
        run: npx lingo.dev@latest i18n
        env:
          LINGODODEV_API_KEY: ${{ secrets.LINGODODEV_API_KEY }}
      - name: Commit translations
        run: |
          git add src/locales/
          git diff --staged --quiet || git commit -m "chore: update translations"
          git push

Every time I update the English source strings and push to main, the Action translates everything and commits the results. No manual translation step, no stale translations, no forgotten locales.

The language switcher UX

On the frontend, switching languages is instant. The useLingoContext hook from Lingo's React integration provides locale and setLocale. A dropdown in the navbar lets you pick any of the 8 languages:

const { locale, setLocale } = useLingoContext();

// When user picks a language
setLocale("ja"); // Switches entire UI to Japanese

I also built a custom toast notification that shows a brief "Translating to Japanese..." message with a spinner when switching — it gives the player feedback that something is happening, even though the switch is nearly instant.

Bugs I hit (and how I fixed them)

No project is complete without war stories. Here are the ones that cost me the most time.

SVG icons turning into gibberish

After enabling the Lingo.dev Compiler, I noticed my SVG icons were broken. The globe icon in the navbar was rendering as literal text: "SVG zero, polygon zero..." The compiler was treating SVG attributes like viewBox and strokeLinecap as translatable text and mangling them.

The fix: Lingo.dev provides a data-lingo-skip attribute. Slap it on any element you don't want translated. I went through every SVG in the codebase and added it:

<svg data-lingo-skip width="16" height="16" viewBox="0 0 24 24"
  fill="none" stroke="currentColor" strokeWidth="2">
  <circle cx="12" cy="12" r="10" />
  <path d="M2 12h20" />
</svg>

This became a pattern — every decorative SVG, every icon, every non-text element gets data-lingo-skip. It's a small thing, but missing even one SVG can break a whole page.

No loading feedback on language switch

The first time someone switched languages, nothing visually happened for a beat. The UI just... changed. Users thought it was broken. I built the TranslationToast component — a small notification that slides in from the bottom-right with a spinner and auto-dismisses after 3 seconds:

<div className="fixed bottom-6 right-6 z-[100] flex items-center gap-3
  rounded-xl border border-border bg-surface px-4 py-3 shadow-2xl">
  <svg data-lingo-skip className="h-4 w-4 animate-spin text-accent" /* ... */ />
  <span>Translating to {languageName}...</span>
</div>

Small touch, big UX difference.

Dev widget stuck on screen

Lingo.dev ships a developer widget that overlays your app in development — useful for debugging translations, but it kept showing up in production screenshots. The fix was a one-liner in the provider config:

devWidget={{ enabled: false }}

The lesson

Compiler-based i18n tools are powerful. They eliminate the drudgery of string extraction and key management. But you need to tell them what not to translate. SVGs, code blocks, brand names, technical terms — anything that shouldn't be localized needs an explicit skip marker. Once I internalized that pattern, the rest was smooth.

What I learned

Compiler-based i18n is a different paradigm. Traditional i18n (react-intl, next-intl, i18next) is key-based: extract every string, assign a key, look it up at runtime. Lingo.dev's compiler approach inverts this — you write natural JSX, and translation happens at the build layer. It's faster to set up, easier to maintain, and eliminates an entire category of "forgot to extract this string" bugs.

Supabase Realtime is underrated for quick multiplayer. I expected to need a dedicated WebSocket server. Instead, four broadcast events and presence tracking gave me a complete multiplayer system. The channel API is clean, the latency is low, and the free tier is generous.

Web Speech API is a zero-cost audio solution. It's not studio quality, but for a game where the point is to identify a language, it's perfect. Dozens of language voices, built into every modern browser, no API keys, no usage fees.

Building for the world from day one changes how you think about UX. When you know your UI will be in Arabic (right-to-left!) and Japanese (longer text strings!), you design differently. Buttons need flexible widths. Text can't be hardcoded into fixed layouts. It's a constraint that makes you a better designer.

Try it yourself

LinguaGuessr is live and free to play.

Live demo URL: https://linguaguessr.vercel.app/
GitHub repo URL : https://github.com/Manjunath3155/linguaguessr

Pick a language. Drop a pin. See how close you get.

If you speak one of the 125+ languages in the database and catch a wrong coordinate or a bad fun fact, open an issue — the whole point is making this better together.

Built for the Lingo.dev Hackathon. If you're building anything multilingual, seriously check out their compiler. It turned what I expected to be a week of i18n plumbing into an evening of configuration.

Built by Manjunath Patil with Next.js, Supabase, Leaflet, and Lingo.dev.