DEV Community: Manjunath Patil

The model is not the product: lessons from building with local Gemma 4

Manjunath Patil — Sun, 24 May 2026 20:11:48 +0000

This is a submission for the Gemma 4 Challenge: Write About Gemma 4

The model is not the product

The easiest mistake to make with a capable local model is to treat the model call as the whole application.

I almost made that mistake while building with Gemma 4 E2B.

My project was a local dementia-care assistant called RememberMe CareGrid. The product goal was not to make a chatbot that sounded clever. The goal was to help a confused patient get calm context, help a caregiver understand what happened, and help trusted community members respond safely.

That changed how I looked at Gemma 4.

Gemma 4 was not the product. Gemma 4 was the reasoning layer inside a product.

The product was everything around it: transcription, context boundaries, consent, structured output, fallbacks, latency, UI state, and the decision to keep answers short when a long answer would be harmful.

That is the main lesson I took away:

Local AI is not just about running a model locally. It is about deciding what the model should own, what the app should own, and what should never be delegated to the model at all.

Why I chose Gemma 4 E2B

Gemma 4 gives developers multiple model choices, and the obvious temptation is to reach for the biggest one.

For my use case, that would have been the wrong instinct.

I chose Gemma 4 E2B because the application needed local, fast-enough, privacy-conscious reasoning. It did not need the largest possible model. It needed reliable short responses and structured care actions.

In a dementia-care workflow, the model may need to answer:

"Who am I?"
"Where am I?"
"Who is Ananya?"
"Am I safe?"
"Who is standing in front of me?"

Those are not questions where a longer answer is automatically better. A confused person does not need an essay. They need one or two calm sentences and one safe next step.

That made E2B a good fit. It is small enough for practical local experimentation, but capable enough to reason over care context and produce useful structured responses.

A larger model could be useful for heavier summarization or complex multi-step analysis, but for the patient-facing loop, model size was not the main bottleneck. Product design was.

That choice taught me that model selection is not a leaderboard decision; it is a product constraint decision.

For this build, the best model was not the biggest model. It was the model that made local assistance practical.

The architecture lesson: separate responsibilities

The breakthrough was realizing that Gemma 4 should not do every job.

In my first mental model, the flow felt simple:

user speaks -> AI responds

In the real system, that was too vague to be useful.

The better architecture was:

audio or text input
  -> transcription if needed
  -> care-context retrieval
  -> Gemma 4 reasoning
  -> structured response validation
  -> UI, watch, phone, or caregiver action

Each component has a different responsibility.

Speech-to-text turns audio into words.
Gemma 4 reasons over the words and care context.
The application validates what actions are allowed.
The UI decides how much information the patient should see.
The caregiver/community flows decide who is allowed to know what.

That separation made the system much easier to debug. If the patient says something and the response fails, I can ask:

Did transcription return text?
Did Gemma 4 receive the right context?
Did the model return valid JSON?
Did the sanitizer reject an unsafe action?
Did the delivery route reach the phone or watch?

Without those boundaries, "the AI failed" becomes an unhelpful explanation. With those boundaries, failures become observable.

JSON mode is useful, but not enough

One of the most important decisions was asking Gemma 4 for structured JSON responses.

For a normal chatbot, a text response may be enough. For a care assistant, text is only part of the output. The system also needs to know the intent, the risk level, and whether an action should happen.

A simplified response shape looks like this:

{
  "reply": "You are Rajamma. You are safe, and Ananya is your care contact.",
  "intent": "patient_identity",
  "risk_level": "medium",
  "action": "notify_caregiver",
  "should_end_session": false
}

This changes the role of the model. Gemma 4 is not just writing a sentence. It is helping select a safe care path.

But JSON mode does not remove the need for validation.

The app still needs to ask:

Is the intent one of the allowed intents?
Is the action one of the allowed actions?
Is the risk level valid?
Is the reply short enough for the patient?
Did the model hallucinate a field that should not exist?

That is why the wrapper matters. The model can suggest. The app must decide what is allowed.

This was the most important safety lesson of the build:

Structured output is not the same as safe output.

You still need a contract around the model.

The UX lesson: do not optimize for impressive answers

AI demos often reward dramatic answers. Dementia-care UX does not.

If the patient is confused, a brilliant paragraph can be worse than a plain sentence. Too much information can increase stress.

So I used three rules for patient-facing responses:

answer in one or two calm sentences
never shame the patient for forgetting
always give one safe next step

For example, if the patient asks "Who am I?", the answer should not be a biographical essay. It should be something like:

You are Rajamma. Your care notes say you sometimes feel unsure, and that is okay. I am here with you, and I am letting Ananya know.

That is not the most technically impressive output Gemma 4 can produce. But it is the right product output.

This is where local models become interesting. Once the model is running close to the application, the developer can design the surrounding behavior very carefully. You are not just prompting a model. You are shaping an experience.

Privacy is an execution path, not a claim

Local inference helps, but it does not automatically make an app private.

That was one of the clearest lessons from building with Gemma 4. Privacy has to show up in the actual flow of the product.

In my care assistant, the privacy boundary looked like this:

the model reasons over care context, but the app controls what context is sent
trusted-person recall only checks against enrolled people
unknown faces are not turned into identities
consent is requested before saving names, photos, or transcripts
community helpers receive role-specific instructions, not full patient history
SOS escalation shares location only when safety logic requires it

That made the privacy work concrete. Gemma 4 running locally reduced the need to send sensitive reasoning to a remote model, but the application still had to enforce the rules around identity, consent, retention, and escalation.

The lesson for me was this:

A local model is a privacy opportunity. The architecture decides whether that opportunity becomes real.

Local AI needs observability

Another lesson: local does not mean simple.

When a cloud API fails, the error is often external. When a local model fails, the problem might be anywhere:

the model is not loaded
the model is loaded but cold
the request timed out
the prompt was too large
the model returned malformed JSON
the local speech recognizer returned no text
the app routed audio to the wrong component

So I added provider metadata and diagnostics around the local flow. The app should know whether the response came from Ollama, which model answered, how long it took, and what failed if something went wrong.

That might sound boring compared with the model itself, but it is what makes a demo feel real.

The difference between a toy and a tool is often not the happy path. It is whether the system can explain what happened when the happy path breaks.

Where Gemma 4 felt strongest

Gemma 4 felt strongest when I gave it a narrow job and a clear output contract.

The pattern that worked best was:

specific context + narrow role + constrained output

That worked better than asking the model to behave like a general-purpose assistant.

It helped with patient cues, caregiver summaries, training cards, and doctor briefs because each task had a bounded role. Gemma 4 did not need to invent the product flow. It needed to reason inside one.

That is the part I would reuse in future projects: do not ask the model to own the whole experience. Give it a precise responsibility inside a system that knows what to do next.

What I would tell another developer

If you are building with Gemma 4, I would not start with "How do I use the biggest model?"

I would start with these questions:

What should the model be responsible for?
What should the application validate?
What should never be delegated to the model?
What does failure look like?
What context does the model really need?
What output shape does the rest of the app expect?
Would a smaller local model create a better product experience?

Those questions matter more than they sound.

Gemma 4 makes local AI feel approachable, but good local AI still needs product boundaries.

Closing

Building with Gemma 4 changed how I think about local models.

The model call is the beginning, not the finish line.

The real work is deciding where the model belongs in the system: what context it gets, what it can output, how the app checks that output, and how the user experiences the result.

For me, Gemma 4 E2B was powerful because it made local reasoning practical enough to place inside a real care moment.

If Rajamma is confused outside her home, the goal is not for AI to sound impressive. The goal is for the system to give one calm cue, notify the right person, and avoid exposing more than necessary.

That is the version of local AI I want more developers to build: not bigger demos, but smaller, safer pieces of intelligence placed exactly where people need help.

RememberMe CareGrid: Local Gemma 4 for dementia memory and safety

Manjunath Patil — Sun, 24 May 2026 19:42:26 +0000

This is a submission for the Gemma 4 Challenge: Build with Gemma 4

What I Built

I built RememberMe CareGrid, a local AI dementia-care prototype powered by Gemma 4 E2B running through Ollama.

I built it as a solo participant, from the dashboard and backend to the Android relay, local model pipeline, and demo flow.

The project is built for people living with dementia, Alzheimer's, or memory loss, and for the caregivers who support them every day.

The moment I designed for is painfully ordinary: Rajamma steps outside, becomes confused, and cannot remember where she is, why she left, or who is standing in front of her. Her caregiver is not physically beside her. A neighbour may want to help, but should not receive private medical details. Later, a doctor may need a clean timeline, but the caregiver may only remember fragments.

RememberMe CareGrid turns that moment into a coordinated care flow.

It gives the patient calm memory context, helps caregivers understand what happened, and lets trusted community helpers respond with only the information they need.

This is not a diagnosis tool. It is not surveillance. It is a consent-aware memory and safety network.

The working prototype includes:

Lumo Companion for patient-facing memory cues
Trusted-person enrollment and recall
SafePath geofencing for wandering safety
SOS escalation with location and risk context
CareCircle task coordination for trusted helpers
CareLearn training cards generated by Gemma 4
Reward wallet gamification for community participation
Doctor Brief generation for clinic-ready summaries

The guiding idea is simple:

Help patients remember less alone, and help caregivers care less alone.

Demo

Direct video link: https://youtu.be/Lz3u-ljxhvA

The demo shows the dashboard, Lumo Companion, local Gemma 4 reasoning, SafePath, CareCircle, CareLearn, trusted-person recall, reward wallet, and Doctor Brief generation.

Code

ladiesmans217 / RememberMe-Caregrid

RememberMe CareGrid

AI memory, wandering safety, community care coordination, and Gemma 4-powered dementia training for Indian families.

RememberMe does not just track dementia patients. It gives them back context: who they met, where they are, what was said, and who can help.

Problem

Dementia care in Indian families is usually handled by one exhausted caregiver. Patients may forget trusted people, recent conversations, medicine routines, and safe routes. Existing tools often stop at GPS tracking or family-only reminders.

Solution

RememberMe CareGrid creates a consent-aware memory layer around a dementia patient. It recognizes enrolled trusted people, remembers meaningful conversations, maps safe places, alerts caregivers during wandering risk, coordinates community helpers, generates CareLearn training resources, and prepares doctor-ready summaries.

Community Impact

The product is built around three rings of care:

Patient: Lumo Companion, SmritiLens, memory cues, SafePath.
Family: caregiver dashboard, alerts, timeline, doctor brief.
Community: neighbour, ASHA worker, pharmacy partner, RWA volunteer, student…

View on GitHub

Repository: https://github.com/ladiesmans217/RememberMe-Caregrid

A few places I would point reviewers first:

src/lib/ai/gemma.ts - Gemma/Ollama reasoning wrapper
src/lib/ai/ollama.ts - local Ollama helper and provider behavior
src/app/api/watch/talk/route.ts - watch-style text conversation route
src/app/api/watch/talk-audio/route.ts - local audio-to-care-response path
src/lib/watch-talk-response.ts - structured response sanitization
src/app/api/generate-doctor-report/route.ts - doctor brief generation
src/app/api/carelearn/generate-training-card/route.ts - Gemma 4 CareLearn cards
src/components/app-shell.tsx - dashboard shell and care navigation

How I Used Gemma 4

Gemma 4 is not used as decoration here. It is the local reasoning layer behind the care workflows.

I used Gemma 4 E2B because this use case needs local, privacy-conscious intelligence more than it needs the largest possible model. Dementia care involves sensitive context: confusion episodes, family relationships, trusted people, location, caregiver notes, and safety status. Sending every interaction to a remote model is not the architecture I wanted to demonstrate.

The core pipeline is:

patient input
  -> local transcription or text
  -> Gemma 4 E2B via Ollama
  -> validated structured response
  -> dashboard / phone / watch-style output

Gemma 4 powers:

patient-facing memory responses
structured Lumo conversation output
SafePath safety guidance
caregiver summaries
CareLearn training cards
doctor-ready weekly briefs
care reasoning and action recommendations

For example, when the patient asks "Who am I?" or "Where am I?", Gemma 4 receives the care context and generates a short, calm response. When SafePath detects that the patient is outside the safe zone, Gemma 4 helps produce a reassuring safety cue instead of a cold alert. When CareLearn needs a neighbour-facing training card, Gemma 4 turns the situation into practical instructions.

The model output is not blindly trusted. Patient-facing responses and actions go through structured JSON handling and sanitization because this is a safety-sensitive workflow. The app expects fields like reply, intent, risk level, action, and escalation state. If the model output is malformed, the app falls back to safer behavior instead of breaking the care loop.

Why I Chose E2B

I chose E2B intentionally. The patient-facing workflow needs short, calm, structured responses, not the largest possible model.

A 31B Dense model would be useful for heavier reasoning, but it would make the local-first care loop slower and harder to run on modest hardware. E2B fits the product goal better: private local inference, fast enough responses, and enough reasoning ability for structured care actions.

For this project, the best model was not the biggest model. It was the model that made local dementia-care assistance practical.

Code Snippets

1. Local Gemma 4 through Ollama, forced into JSON mode

Source: src/lib/ai/ollama.ts

This is the core local model contract. The app calls Ollama locally, keeps Gemma warm, disables streaming for structured route responses, and asks the model for JSON so downstream patient actions can be validated.

export async function generateJson<T>(prompt: string, fallback: T): Promise<T & AiProviderMetadata> {
  const started = Date.now();

  try {
    const res = await fetchWithTimeout(`${OLLAMA_URL}/api/generate`, {
      method: "POST",
      headers: { "Content-Type": "application/json" },
      body: JSON.stringify({
        model: OLLAMA_MODEL,
        prompt,
        stream: false,
        format: "json",
        keep_alive: OLLAMA_KEEP_ALIVE,
        options: { temperature: 0.2, num_predict: 512 }
      })
    }, OLLAMA_TIMEOUT_MS);

    const data = (await res.json()) as OllamaGenerateResponse;
    const text = data.response || data.message?.content || "";
    if (!text.trim()) throw new Error("Ollama returned an empty JSON response");

    const parsed = JSON.parse(extractJson(text));
    return withMetadata(parsed as T, {
      _provider: "ollama",
      _model: data.model || OLLAMA_MODEL,
      _elapsed_ms: Date.now() - started
    });
  } catch (error) {
    return withMetadata(fallback, {
      _mock: true,
      _provider: "ollama",
      _model: OLLAMA_MODEL,
      _error: errorMessage(error),
      _elapsed_ms: Date.now() - started
    });
  }
}

2. Watch audio becomes local transcription, then Gemma reasoning

Source: src/app/api/watch/talk-audio/route.ts

Gemma 4 is not treated as an audio transcription model. The watch audio is transcribed locally first, then the transcript is sent into the same Gemma-powered care reasoning path.

async function processAudioTalk(input: AudioTalkInput, progress?: ProgressWriter) {
  progress?.("audio_received", {
    audio_bytes: input.audioBytes,
    mime_type: input.mimeType,
    asr_url: getAsrConfig().url
  });

  const asr = await transcribeLocalAudio({
    audio: input.audio,
    filename: input.filename,
    mimeType: input.mimeType
  });
  const transcript = asr.transcript.trim();

  if (!asr.ok || !transcript) {
    const code = asr.error ? "local_asr_failed" : "local_asr_empty_transcript";
    await logAudioFailure(input, code, `Local ASR failed for session ${input.sessionId}.`);
    return audioFailure(input, code, { asr: summarizeAsr(asr) });
  }

  progress?.("transcribed", { transcript, asr: summarizeAsr(asr) });
  progress?.("thinking", { message: "Thinking with local Gemma" });

  return handleWatchTalkTranscript({
    transcript,
    patientId: input.patientId,
    sessionId: input.sessionId,
    route: "/api/watch/talk-audio",
    inputMode: "audio",
    diagnostics: { audio_bytes: input.audioBytes, asr: summarizeAsr(asr) }
  });
}

3. Gemma output is sanitized before it can affect the patient flow

Source: src/lib/watch-talk-response.ts

For a dementia-care workflow, the model cannot be allowed to return arbitrary action strings. This sanitizer constrains the reply, intent, risk level, action, and session-ending flag before anything is shown or executed.

export function sanitizeWatchTalkResponse(input: unknown, fallback: WatchTalkResponse): WatchTalkRouteResponse {
  const source = input && typeof input === "object" ? input as Record<string, unknown> : {};
  const reply = cleanReply(source.reply, fallback.reply);
  const intent = oneOf(source.intent, intents, fallback.intent);
  const risk_level = oneOf(source.risk_level, riskLevels, fallback.risk_level);
  const action = oneOf(source.action, actions, fallback.action);
  const should_end_session = typeof source.should_end_session === "boolean" ? source.should_end_session : fallback.should_end_session;

  return {
    reply,
    intent,
    risk_level,
    action,
    should_end_session,
    ...metadata(source)
  };
}

function cleanReply(value: unknown, fallback: string) {
  const reply = typeof value === "string" ? value.replace(/\s+/g, " ").trim() : "";
  return (reply || fallback).slice(0, 360);
}

function oneOf<T extends string>(value: unknown, allowed: ReadonlyArray<T>, fallback: T) {
  return typeof value === "string" && (allowed as ReadonlyArray<string>).includes(value) ? value as T : fallback;
}

4. The same Gemma helper powers care features beyond chat

Sources: src/app/api/carelearn/generate-training-card/route.ts and src/app/api/generate-doctor-report/route.ts

The same local Gemma helper is reused for two different care workflows: community training and doctor-ready summaries. This is the part that makes the project feel like a care system instead of a single chat screen.

// CareLearn: role-specific dementia-care training cards
export async function POST(request: Request) {
  const body = await request.json().catch(() => ({}));
  const role = (body.role || "neighbour") as Role;
  const useCase = body.use_case || "wandering";
  const eventContext = body.event_context || "Rajamma left safe zone near MSRIT gate.";
  const data = await generateJson(trainingPrompt(role, useCase, eventContext), mockTrainingCard);
  return NextResponse.json(data);
}

// Doctor Brief: clinic-ready caregiver summary
export async function POST(request: Request) {
  const body = await request.json().catch(() => ({}));
  const fallback = mockDoctorReport();
  const generated = await generateJson(doctorReportPrompt(body.state || {}), fallback);
  return NextResponse.json({
    ...fallback,
    ...generated,
    id: generated.id || uid("doctor_report"),
    patient_id: generated.patient_id || DEMO_PATIENT_ID,
    created_at: generated.created_at || new Date().toISOString()
  });
}

Consent Model, Not Just a Promise

It is easy to say "this is not surveillance." The important part is designing the system so that statement is true.

RememberMe CareGrid uses a consent-aware flow:

trusted people must be enrolled before they can be recognized
unknown people are not labeled as identities
unknown faces are not turned into memory profiles
patient-facing capture flows ask for consent before saving names, photos, or transcripts
helper tasks expose limited role-based information instead of full medical history
safety alerts share location and risk context only when escalation is needed

That distinction matters. The phone relay can capture a frame, Firebase can sync care state, and Twilio can send SOS messages, but those tools are wrapped around a care workflow with enrollment, consent, retention, and role limits.

The goal is not to watch the patient. The goal is to reduce the time between confusion and safe help.

UX Choices for Dementia Care

I designed the AI responses around three rules:

answer in one or two calm sentences
never shame the patient for forgetting
always give one safe next step

That is why Lumo does not behave like a normal chatbot. A long answer may be technically impressive, but it can overwhelm someone who is already confused.

The same principle applies to community helpers. They receive limited role-based instructions, not the patient's full private history. The product is designed to make help easier without exposing more information than needed.

Main Workflows

Lumo Companion

Lumo is the patient-facing companion. It gives short, respectful memory cues.

The patient can ask:

"Who am I?"
"Where am I?"
"Who is Ananya?"
"Who is in front of me?"

The response is intentionally not a long chatbot answer. In dementia care, the best answer is often the one that reduces fear and helps the next safe action happen.

Trusted-Person Recall

A caregiver can enroll trusted people. The system stores consented trusted-person embeddings.

If the patient cannot remember who is standing in front of them, the phone relay captures a frame and compares it only against enrolled trusted-person embeddings. If there is a match, the patient receives a gentle cue.

Unknown people are not identified or stored. The system recognizes trusted people, not strangers.

SafePath

SafePath checks whether the patient is inside or outside a safe zone.

If the patient leaves the intended radius, the system creates a risk event and can trigger escalation with location context. The patient message remains calm, for example:

You are outside the safe zone. You are not alone. Please stay near a familiar place. Ananya is being contacted.

SafePath is not only a map. It is the part of the system that turns location into a care decision: reassure the patient, notify the caregiver, and give helpers enough context to respond safely.

CareCircle

CareCircle turns alerts into role-based tasks.

The important design choice is that not everyone gets the same information. A caregiver may need a detailed event timeline. A neighbour may only need a simple request: "Rajamma may need help near the temple gate. Please contact Ananya." A community health worker may need visit context. A pharmacy partner may need refill-related context. A local safety volunteer may need an emergency protocol.

This is where RememberMe CareGrid becomes more than a patient app. It becomes a coordination layer for trusted care.

CareLearn and Rewards

CareLearn uses Gemma 4 to generate role-specific dementia-care training cards.

The training is tied to real care moments. If a wandering event happens, the system can generate a card for a neighbour explaining how to approach calmly, what not to say, and when to notify the caregiver. If medication confusion happens, it can generate a different card for a pharmacy partner or caregiver.

The reward wallet adds a small gamification layer. Helpers earn points for completing training and can redeem them in the demo for care-related rewards such as pharmacy support, safety kits, or caregiver respite vouchers.

The point is not points for the sake of points. The point is to make community readiness visible and repeatable.

Doctor Brief

Doctor Brief converts scattered care events into a clinic-ready summary.

It can include medication adherence, wandering events, known visitors, memory journal topics, health snapshots, caregiver notes, community health worker notes, and suggested discussion points. The goal is to help a caregiver walk into a doctor visit with structured context instead of relying on memory during a stressful appointment.

Technical Architecture

The architecture is split around responsibility: Gemma 4 reasons, local transcription handles speech, Firebase synchronizes care state, the Android relay handles camera capture, and the app validates every model response before it becomes a patient-facing action.

The prototype uses:

Next.js for the web dashboard
Firebase for live care state, cues, GPS events, alerts, relay state, and training progress
Android phone relay for trusted-person recall
Gemma 4 E2B through Ollama for local reasoning
local speech-to-text before Gemma reasoning
face embeddings for consented trusted-person matching
SafePath geofencing
Twilio for SOS-style call and SMS workflows
structured JSON validation for patient-facing responses and actions

This is not only a UI mockup. The demo connects model reasoning, phone relay, live sync, geofence safety, community tasking, training, rewards, and doctor summaries into one care network.

What Was Hard

The hardest part was not calling Gemma 4. The hard part was making local Gemma 4 behave like one component inside a safety-sensitive product.

The first design problem was speech. A remote multimodal API can hide transcription and reasoning inside one call. Gemma 4 E2B in this local setup should not be treated as an audio transcription model. So I split the pipeline: local speech-to-text first, then Gemma reasoning over clean text and care context. That made the system more honest and easier to debug.

The second problem was structure. A normal chatbot answer is not enough here. The watch flow needs to know whether the response is just an answer, a caregiver notification, a camera-frame request, or an end-session action. That is why the output is constrained and sanitized before the app uses it.

The third problem was timing. In the trusted-person recall flow, the phone relay, dashboard state, and watch-style cue delivery all have to line up. A result that arrives too late is not useful to the patient. I had to treat latency and state sync as product problems, not just backend problems.

The main lesson was that assistive AI is not only about model capability. It is about the boundary around the model: what context it receives, what it is allowed to output, and how the product behaves when something fails.

What I Would Improve Next

The next version would replace the phone relay with a low-cost wearable camera module, improve offline deployment on mobile or wearable hardware, refine localized voice UX, expand caregiver-controlled consent settings, and validate the workflows with elder-care groups, clinics, and community health workers.

I would also continue optimizing local Gemma 4 inference so the patient-facing experience feels faster on modest hardware.

Closing

RememberMe CareGrid is built around one belief:

Dementia care should not depend on one exhausted caregiver remembering everything alone.

Gemma 4 makes it possible to build local, private, useful intelligence around people who need support in the moment.

This prototype proved to me that local AI can be more than a private chatbot: it can become a careful coordination layer between a patient, a caregiver, and trusted helpers.

RememberMe CareGrid helps patients remember less alone, and helps caregivers care less alone.

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.