As a Customer Engineer at Google Cloud, my day job revolves around helping developers leverage our serverless stack — think Cloud Run, Firebase App Hosting, and the magic of Gemini Code Assist. Firebase Platform was the first ever Cloud product I used, so it holds a particularly special place in my toolkit. But when I am away from my laptop you’ll often find me cycling, sometimes for very long distances.
This year, I’m tackling a monumental challenge outside of work: Lost Dot’s Transcontinental Race (TCRNo11). We’re talking nearly 5,000 kilometers of solo, unsupported cycling across Europe’s stunning (and demanding) landscapes. Planning is crucial, especially for the basics: finding food, water, and the occasional place to sleep without derailing the race clock. Manually plotting Points of Interest (POIs) like supermarkets or 24-hour gas stations along a 5,000km route using tools like Ride With GPS takes hours, involving endless zooming, clicking, and checking opening times.
This sparked an idea: could I merge my passions? Could I use Firebase and AI to automate finding essential POIs along a GPX defined race route (a GPX file is a format used for GPS data like waypoints, routes, and tracks for navigation devices)? Could I leverage the power of the Google Maps Platform APIs and store this data in Firestore for easy access, maybe even open the door to future AI-powered insights?
The answer, powered by Firebase and Gemini, turned out to be a resounding yes. And so began my journey into “Vibe Coding” an app to help conquer the road ahead.
My goal was clear: build an app that takes a GPX route file, parses it, and automatically plots key POIs (supermarkets, water sources, potential lodging) along the path, filtering them for cyclist-specific needs like proximity to the route and opening hours.
My approach? Vibe Coding. Forget rigid specs and months of planning. Start with the core idea, dive in using rapid prototyping tools, iterate quickly, and focus on building something useful, not perfect (at least initially!).
Here’s how the tech stack came together:
- Scaffolding with Firebase Studio prototyper: I started with Firebase Studio Google’s browser-based development environment. Its built-in Gemini 2.5 powered prototyper was perfect for vibe coding. I could describe the UI and logic I wanted (“a map view, a file upload button for GPX files, and a list to display POIs”) and Gemini would generate the initial React components and layout using Tailwind CSS. This got me from zero to a compiling Next.js app incredibly fast.
- Parsing the Path: Once the GPX file was uploaded, I needed to parse the XML data to extract the latitude/longitude coordinates that define the route. A simple prompt with Gemini in Firebase helped generate the necessary server side function.
- Finding POIs with Gemini & Google Maps Platform: This was the core challenge and where AI really shone. Instead of writing geospatial query logic myself I prompted Gemini (in it’s various forms; see the tricks below to find out how) to solve the problems. Prompts like “Given this series of GPS coordinates representing a cycling route segment, find supermarkets using the Google Maps Places API that are within a 2km detour of any point on this segment and return their name, coordinates, and opening hours.”
- Similarly, I prompted for cafes, hotels, and 24-hour gas stations. Gemini interpreted the natural language request, formulated the necessary queries for the Google Maps Places API behind the scenes (or guided me on the API call structure), processed the results, and filtered them based on my criteria (like “24-hour availability”).
- Storing Data in Firestore and Cloud Storage: The identified POIs (name, coordinates, type, hours) were saved to a Firestore database, linked to the specific route in Cloud Storage. This allows for quick retrieval and display on the map, and potentially for offline access or sharing later.
- Effortless Deployment with Firebase App Hosting: Getting the prototype live was literally a few clicks using Firebase App Hosting. It automatically handled the build process, deployed the app to Cloud Run with a managed network layer. This rapid deployment cycle was key for quick testing and getting feedback from fellow cyclists.
Here’s what the final vibed product looks like for a ultra cyclist trying to find POIs on their route:
I have estimated POI plotting for my 5,000km TCR route, Gemini and Firebase has saved me 2.2 days.
Below are the unscientific estimates of how I figured this out and what an example return on investment might look like.
If I was to manually plot Points of Interest (POIs) with Ride With GPS below are the steps I would take, and the approximate time to complete:
- Load GPX: 60sec
- Toggle to Google Maps view: 2sec
- Repeatedly work my way along the route with the map to find a POI: 60sec per 2km
3.1 Click to add a POI, change type, type name of POI: 60sec
3.2 Click to add a custom cue, type name of POI: 60sec
3.3 Click on the Fuel station to view on Google Maps: 10sec
3.4 Find opening hours and add to the POI Name: 60sec - Save route: 2sec
So the total approximate time for every 100km (given 1–2 POIs every 10 km) manually is therefore 1 hr 22 min 44 sec. So for TCR and 5,000km of plotting, it would take me 2.9 days. That’s a long time.
To compare to vibe coding this and using the finished product, I need to take into account an estimate of the total vibe code time and any other Cloud related technical activities in addition to using the app to plot the POIs. To estimate the time, I took the measurement of prompt writing as the main input and factored for the general Cloud setup and tasks on the side (e.g. creating an API key for Google Maps Places API).
Total number of commits = 38
Estimated time to write a prompt = 120sec per prompt
Estimated prompts per commit = 4
Infrastructure setup, security and key management = 18000sec
Debugging, error management and misc = 18000sec
So the total approximate vibe code development time was 15 hr 4 min 0 sec. Essentially, two working days.
So if we take the example of me planning 5,000km or routes, what is the return on investment? The total approximate time for every 100km (given 1–2 POIs every 10 km) with the vibe coded app is around 0 hr 1 min 14 sec. With this and the total development time in mind, my return on investment comes if I use this app for plotting POIs for 1,100km of route; just over 15 hrs either manually or vibe coding.
Commit early and often to your own repo
As soon as Studio generated the initial code, I connected it to a new GitHub repository. This creates a valuable commit history. You can see exactly where Gemini generated code (often noted in the commit message).
Know your Gemini
“Using Gemini” isn’t monolithic. I leveraged AI in several ways as the git history shows:
- Gemini 2.5 Prototyper in Firebase Studio: For generating the initial application structure, UI components (React), and features based on high-level prompts. I also used the client side error code fixer tooling here too.
- Gemini in Firebase: Comes pre-baked into Firebase Studio if you choose to use it. I used it for the heavy lifting — complex analysis, interpreting natural language requests for POIs, and interacting with the Google Maps Places API based on route context.
- Gemini Code Assist: This is using the extension downloaded from Marketplace and authenticated with my Gemini Code Assist Enterprise project. This is also handy for inline code completion, explanations, generating documentation, and suggesting refactoring within the actual code files.
- Gemini: For context agnostic queries, or for standalone features or advice on Firestore database structuring.
This multi-tool approach mirrors a modern developer workflow: use the best AI tool for the specific task at hand. My role shifted from writing every line of code to architecting the system, crafting effective prompts, guiding the AI, and integrating the generated pieces.
Prototyper Select Tool
By using the Select tool in the prototyper screen, you can select elements on a page to target what UI feature you wish to change. This is really handy for quick small changes in isolation.
Logging and monitoring
As you are vibing away in the Firebase Studio IDE and you are running server side code, it’s hard to figure out where the logs are going if you are using Studio’s built in preview. If you switch to the code view,open a terminal and select the OUTPUT tab, then you’ll see all the console.logs() output here. Really handy as the Studio only seems to pick up on client side logging and Errors.
For all the client side logging, the web console experience under the hot reload preview is brilliant. No need to right click inspect to get the console up on screen!
Security and environment variables
Ensure you check what is being committed. I had to check to ensure that the gitignore was ignoring my .env file. Turns out for my iteration it wasn’t, so ALWAYS double check what is being prototyped. Don’t just trust blindly, a bit of common sense goes a long way.
Gemini in Firebase with 2.5 Pro
Did you know you can change the model used in Gemini in Firebase? It’s pretty nifty. You can even bring your own model and configure it in the Studio settings if you have an API key already.
Connecting to a database or other services using Application Default Credentials (ADC)
When you use Firebase App Hosting to serve your app in production, it handles all the service account credentials using Application Default Credentials (ADC) by default. However when we want to try this locally, without the Firebase Emulator suite that is, we need to authenticate the Studio instance to talk to the database. And of course, we all don’t use Service Account JSON keys to do this right? Therefore in order to connect to a service using your ADC credentials, I found I needed to login and set the quota project. Simple to do but one trick that might be worth noting.
Lessons from the Road (and the Code)
This project reinforced some core development philosophies:
- Start now, perfect later: Don’t let the pursuit of perfection paralyze you. If you have an idea that solves a real problem for you, start building. My POI Plotter is functional, not flawless, but it’s already saving me hours of planning.
- Scratch your own itch: The most motivating projects are often born from personal necessity. Even if only a handful of people ever use your app, the learning experience and the utility you gain are invaluable.
- AI as your sous-chef: You don’t need to aim for a production-ready app from day one. But if you decide to scale or share more widely, leverage AI. Before truly “shipping” this, I’d use Gemini to review the code for security vulnerabilities, suggest performance optimizations, improve accessibility, and even generate user documentation. It’s like having an incredibly versatile coding partner.
- Deploy & share instantly: Tools like Firebase App Hosting democratize deployment. Getting your creation into the hands of users (even if it’s just friends) provides crucial feedback and motivation.
So, as I gear up to pedal across Europe, I’ve got my bike, my gear, and a custom-built route planning tool, created with a healthy dose of Vibe Coding and a lot of help from Firebase and Gemini.
What personal challenge could you tackle with this approach? Give it a try — you might surprise yourself.
Wish me luck for TCRNo11!
Source Credit: https://medium.com/google-cloud/vibe-coding-a-5-000km-bike-race-building-a-route-planner-with-firebase-gemini-cec624d79221?source=rss—-e52cf94d98af—4