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

#devchallenge #githubchallenge #githubcopilot #nextjs

GitHub “Finish-Up-A-Thon” Challenge Submission

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.