DEV Community: Christopher Mburu

From Hidden Data Loss to Reliable Bookings: Finishing Demic Ride with GitHub Copilot

Christopher Mburu — Fri, 05 Jun 2026 12:33:35 +0000

This is a submission for the GitHub Finish-Up-A-Thon Challenge

What I Built

Demic Ride is a corporate taxi dispatch and ride-hailing platform for Demic Tours Africa, built on Next.js, Supabase, and Tailwind, deployed on Render at ride.demicafrica.com. It handles passenger booking, automatic driver dispatch, live GPS tracking, and a pay-after-ride flow.

The MVP was already live — but "live" hid a problem. A booking form that looked finished was silently throwing away data on every submission. Finishing this project meant catching the bug that nobody had noticed because it never produced an error.

Demo

Live: ride.demicafrica.com
Repo (challenge branch): Demic-Africa/demic-ride @ finish-up-athon

The Comeback Story

Before vs After

Before

Schedule data was collected but not stored
Missing database columns
Weak validation around booking schedules
Dispatch failures were not handled gracefully

After

Schedule data persists correctly
Database migrations are version controlled
Validation prevents incomplete bookings
Dispatch failures no longer break the booking workflow
Analytics dashboard provides operational visibility

What I changed:

Added the missing columns via a version-controlled migration (scheduled_date, scheduled_time, notes). The schema had only ever lived in the Supabase dashboard, so this also put it into git for the first time.
Added real validation for date/time, with an inline error instead of a native alert().
Wrapped dispatch in try/catch so a failure now saves the booking and shows an honest "driver will be assigned shortly" state instead of a fake success.

One honest note: the booking failure I first screenshotted turned out to be the Supabase project auto-pausing on the free tier, not a code bug — resuming it restored bookings. The real, code-level issue was the silent data loss above. I kept that distinction clear in my project journal.

My Experience with GitHub Copilot

I used Copilot in two distinct ways, and I want to be precise about which was which.

As a reviewer for the fixes above. I'd written the migration, validation, and error handling, then ran them past Copilot with my repo as context to check my work and confirm root cause. In one session I asked it to update the date/time validation — and it correctly told me the validation was already right, pointed at the exact line, and suggested a more granular per-field error pattern instead. In another it walked the booking-failure root cause and explained exactly why the missing columns caused silent data loss. Having an AI confirm or push back on a fix you've already made is underrated: it caught nothing catastrophic, but it tightened my reasoning and my dispatch error-handling pattern.

As an author for net-new code: the fleet analytics dashboard. This one Copilot built. I gave it my real bookings and drivers columns and asked for an admin analytics component using the app's existing styles. It generated the component; I corrected the one thing it guessed wrong (the driver-status query column), wired it into an /admin/dashboard route, and it rendered live data on the first build.

Example: Database Migration

Prompt:

"Generate a Supabase migration to add scheduled_date, scheduled_time, and notes columns using IF NOT EXISTS."

Copilot Output:

Generated migration structure
Suggested safe ALTER TABLE statements
Explained rollback considerations

Outcome:

The missing fields were added and booking schedule data now persists correctly.

Links

Repository:
https://github.com/Demic-Africa/demic-ride/tree/finish-up-athon

Live Demo:
https://ride.demicafrica.com

Hermes TravelOps: An Agent That Learns From Every Trip

Christopher Mburu — Sun, 31 May 2026 17:13:27 +0000

What I Built

Hermes TravelOps Agent — an autonomous travel operations manager built natively on Hermes Agent. It remembers each traveler's preferences without prompting, researches flights and hotels via web search, flags risks, and runs a post-trip debrief that rewrites its own memory so the next trip plan is automatically different. No external backend: memory, skills, and scheduling are all Hermes's own.

The Problem

Travel coordinators repeat the same operational loop for every trip: research flights and hotels against a traveler's quirks, check visas, assemble an itinerary, monitor for disruptions, and — the part every tool ignores — learn from how the trip actually went. Most AI travel tools answer a question and forget you. I wanted one that operates and remembers.

Architecture: Hermes IS the Stack

~/.hermes/
├── skills/
│   ├── travel-plan-request/SKILL.md   ← Multi-step planning
│   └── post-trip-debrief/SKILL.md     ← Learning loop
├── context/
│   └── TRAVEL_OPS_CONTEXT.md          ← Domain knowledge
├── memories/
│   └── MEMORY.md                      ← Persistent memory (FTS5)
└── SOUL.md                            ← Agent persona

Hermes handles memory, web search, skill execution, and scheduling natively. It's model-agnostic — this demo runs on gemini-3-flash-preview through Hermes's provider layer, and nothing in the project depends on which model sits underneath.

Demo data is seeded. I loaded two traveler profiles and one prior-trip record into memory before recording, so the learning loop has history to work against. Trip dates are fixture data, not live calendar events. What the agent does — recall, research, debrief, re-plan — is real and unscripted.

The Demo

Command 1 — Plan a trip: Plan a trip for Sarah to Dubai next week

Hermes loaded the planning skill, fired three web searches, and returned one recommendation with every stored preference already applied — without me restating any of them: Emirates EK720, window seat (enforced), vegetarian (matched), non-stop, Marriott Palm Jumeirah, WiFi 5/5, visa valid to 2027-03-15, ~$850, ending at "pending approval."

Command 2 — Visa check: Check visa for Sarah going to UAE → Valid, multi-entry, expiry 2027-03-15, no action required.

Command 3 — Post-trip debrief: Sarah is back from Dubai. Emirates was 4/5 but the layover in DXB was 6 hours and she was frustrated.

This triggered the post-trip-debrief skill. The memory tool fires repeatedly in the recording — including failed lookups before the write lands, which is what a real agent retrying looks like. It marked the 6hr layover "strictly unacceptable," added a directive to enforce direct Emirates flights for NBO-DXB, and wrote the lesson to memory.

Command 4 — Prove the memory changed: cat ~/.hermes/memories/MEMORY.md | grep -A2 "Sarah Chen"

The file now reads max 3hr layover and carries the dated lesson. It changed because the agent rewrote it — no update script, no external database.

Command 5 — Re-plan, watch it apply what it learned: Plan another trip for Sarah to Dubai next month

With zero prompting, the new plan enforced the constraint the debrief created: non-stop only, "EK720 selected explicitly to avoid the 6-hour layover friction reported in June," and Marriott Palm Jumeirah prioritized over Business Bay on a previously-logged WiFi rating.

Why This Uses Hermes Properly

Build criterion #1 is "effective use of Hermes Agent's agentic capabilities." I used Hermes native memory (FTS5 + MEMORY.md) instead of a database, Hermes skills instead of custom orchestration, Hermes built-in web search instead of a bolted-on service, and a skill-driven post-trip loop that writes back to memory and changes future behavior. A handful of files, no infrastructure, model-swappable underneath.

Try It Yourself

git clone https://github.com/tourswithchris/hermes-travel-ops-native.git
cd hermes-travel-ops-native
cp -r skills/* ~/.hermes/skills/
cp context/TRAVEL_OPS_CONTEXT.md ~/.hermes/context/
cp memories/* ~/.hermes/memories/
cp SOUL.md ~/.hermes/
hermes chat
# Then: Plan a trip for Sarah to Dubai next week

Repo: https://github.com/tourswithchris/hermes-travel-ops-native