DEV Community: Christopher Mburu

I Skipped the Custom Backend: Why n8n + Supabase Won for Our Safari Operation

Christopher Mburu — Sat, 08 Aug 2026 09:01:58 +0000

Six months ago, if you'd asked me how Demic Africa — a luxury safari and ground transport company operating out of Nairobi — handled booking logistics, I would have pointed at a spreadsheet and a WhatsApp inbox held together by muscle memory. It worked, in the way that things work right up until the moment a $90 Executive SUV transfer and a $45 Standard Transfer both need to be at the airport at the same time and nobody flagged the conflict.

At some point "it works" stops being good enough, but "we need a full custom stack" is also the wrong answer for a business our size. This is the story of the middle path I picked — n8n for orchestration, Supabase for data and why I think it's the right call for where we are right now, not necessarily where we're headed.

The problem: too big for spreadsheets, too small for a custom stack

Demic Africa runs a handful of interlocking workflows: inbound leads from Meta and Google ad campaigns, ground transport dispatch across two tiers of vehicles, multilingual guest communication (English, Arabic, French, Turkish) over WhatsApp and Instagram DM, and safari booking coordination across partner camps in Kenya, Tanzania, and Uganda.

None of that is exotic. None of it needs a distributed systems architecture. But all of it needs to be reliable — a lead can't sit unanswered for six hours because I was on a call, a driver assignment can't get overwritten by a copy-paste error, and a guest confirmation can't silently fail to send.

The honest failure mode of a small operator isn't "our system can't scale." It's "our system depends on a person remembering to do a manual step at 11pm." Spreadsheets don't fix that. Neither does hiring a developer to write bespoke integration code for every new channel we plug in, which is where I started leaning before I talked myself out of it.

Why n8n won over custom integration code

I write Python regularly, so "just build it" was a real option, not a cop-out. I decided against it for a few concrete reasons that are specific to this stage of the business rather than automation orthodoxy:

The bottleneck isn't logic, it's plumbing. Most of what needs to happen — new lead comes in, check vehicle availability, notify the right driver, send a WhatsApp confirmation, log it to the booking register — is a sequence of API calls between services I don't control (Meta, WhatsApp, Google Sheets/Supabase, email). Custom code for that is mostly writing and maintaining auth handling and error retries for other people's APIs. n8n already does that part well, and it does it visually enough that I can hand off a workflow explanation to someone who isn't a developer.

As the only engineer, and I'm not always the one debugging. When something breaks in a bash script at 6am Nairobi time before a guest transfer, I need to see where it broke without SSHing into a server and reading logs. n8n's execution history gives me that for free — I can look at a failed run, see the exact node and payload that failed, and fix it from my phone if I have to.

Iteration speed matters more than architectural purity right now. Every week I'm adjusting something — adding TikTok as a lead channel, changing how child pricing (ages 4–12, under 4 free) gets applied in a quote, tweaking the multilingual reply logic. In custom code, each of those is a deploy. In n8n, most of them are a node change and a save.

The trade-off is real: n8n workflows get messy at scale, version control is awkward compared to a git repo, and there's a ceiling on how much genuinely custom business logic I want to cram into Function nodes before it's fighting the tool. I'm not pretending otherwise. But for the current transaction volume, the plumbing-vs-logic ratio strongly favors n8n.

Why Supabase over a heavier managed database

For data, I didn't seriously consider running my own Postgres instance, and I didn't want a heavier managed platform either. Supabase hit the right point for a lean team for a few reasons:

It's still just Postgres. I'm not locked into a proprietary query layer. If Demic Africa outgrows Supabase, the migration path is "move a Postgres database," not "rewrite a data layer."
Auth, storage, and row-level security come bundled. I don't need a separate service to handle guest-facing auth for something like a booking portal, and I don't need to hand-roll access control between what a driver can see versus what an admin can see.
n8n talks to it natively and cheaply. The Supabase node in n8n is a straightforward Postgres/REST bridge, so the orchestration and data layers don't fight each other. That matters more than people expect — a lot of "custom backend" pain is really integration friction between the pieces, not any one piece being hard on its own.
The free/low tiers match our actual load. A heavier managed database is priced and provisioned for a transaction volume we don't have yet. Paying for headroom I'm not using is capital that should be going toward ads or ops instead.
What I'd reconsider once volume grows

This stack is a bet on the current stage of the business, not a permanent architectural stance, and I want to be specific about where it bends:

Workflow sprawl in n8n. Past a certain number of interlocking workflows, visual orchestration becomes its own kind of technical debt — nodes referencing other workflows, shared logic duplicated instead of abstracted. I'd expect to peel off the most complex, highest-stakes logic (real-time dispatch conflict resolution, for instance) into dedicated services before that becomes unmanageable.
Concurrency and queuing. n8n's execution model is fine for the request volume we have. It is not designed for high-throughput, low-latency dispatch decisions happening in parallel across many vehicles at once — if we're managing a much larger fleet with real-time conflicts, that logic needs to live somewhere built for concurrency, not a workflow canvas.
Multi-region and compliance requirements. If Demic Africa expands into markets with stricter data residency requirements, Supabase's hosting model may need to change, or I may need more control over where data physically lives than a managed platform gives me by default.
Cost curve inversion. Managed tools are cheap until they aren't. If usage-based pricing on either platform starts approaching what a dedicated engineer or self-hosted infrastructure would cost, that's the signal to revisit, not a fixed timeline.

None of that is a reason to over-build now. It's a reason to keep the decision explicit and revisit it against real usage numbers instead of vibes.

The actual lesson

The interesting decision for a small operator usually isn't "no-code versus custom code" as a philosophy. It's matching the tool to the actual bottleneck at the actual stage you're at, and being willing to say out loud what will make you change your mind later. Right now, for Demic Africa, that bottleneck is reliable plumbing between services I don't control and n8n plus Supabase closes that gap without asking me to build and maintain a backend I don't need yet.

If you're running a small ops-heavy business and weighing the same trade-off, I'd rather hear what broke for you than what worked — reply below or find me on X/LinkedIn.

From AI Chatbots to AI Operators: Why Travel Doesn't Need Another Assistant

Christopher Mburu — Mon, 13 Jul 2026 08:55:07 +0000

Most AI tools in travel can answer questions. Very few can actually do the work.

A delayed flight.
A missed airport transfer.
A hotel overbooked at midnight.
A client changes destinations while already in transit.
These aren't customer support problems.
They're operations problems.

Yet much of today's AI conversation is still focused on building assistants that generate impressive responses instead of systems that execute reliable workflows.
After spending the last several months building autonomous travel agents, I've become convinced that we're asking AI the wrong question.

Instead of asking:
"Can AI answer this?"
we should be asking:
"Can AI own this process from start to finish?"

The Hidden Cost of Modern Travel Operations
Travel companies don't lose most of their time answering FAQs.
They lose it managing fragmented information.

A typical booking touches multiple systems:

CRM
Email
WhatsApp
Supplier confirmations
Flight updates
Hotel vouchers
Transfer schedules
Customer preferences
Internal spreadsheets

The problem isn't lack of data.
It's that every piece of information lives somewhere different.
Humans become the integration layer.
That doesn't scale.

The Shift: From AI Assistants to AI Operators
Most AI assistants work like this:

Question
        ↓
Large Language Model
        ↓
Answer

Useful?
Absolutely.
Finished?
Not even close.
An AI operator looks different:

Booking received
        ↓
Verify traveler profile
        ↓
Check supplier confirmations
        ↓
Monitor flights
        ↓
Detect risks
        ↓
Notify operations
        ↓
Rebook if required
        ↓
Update CRM
        ↓
Learn from outcome

Notice something?
The user may never even talk to the AI.
The work simply gets done.

Memory Changes Everything
One capability I believe remains underrated is persistent operational memory.
Most AI forgets everything after the conversation ends.
Operations cannot.
Imagine an agent remembering that a traveler:

always prefers aisle seats,
avoids overnight layovers,
celebrates anniversaries while travelling,
requires vegetarian meals,
usually books airport transfers after landing.

Now imagine it applying those preferences automatically across future bookings.
No prompts.
No repeated instructions.
Just accumulated operational knowledge.
That's where autonomous systems begin to create real value.

Building Hermes TravelOps
This idea led me to build Hermes TravelOps—an autonomous operations agent for travel businesses.
The goal wasn't another chatbot.
The goal was something that behaves more like an experienced operations coordinator.
An ideal operational agent should be able to:

monitor bookings continuously,
detect potential disruptions before customers notice,
preserve organizational knowledge,
coordinate multiple workflows,
improve after every completed trip.

The interesting engineering challenge isn't generating text.
It's designing systems that remember, observe, decide, and execute safely.

The Hard Part Isn't AI
Ironically, the hardest part hasn't been prompting large language models.
It's engineering everything around them:

state management,
workflow orchestration,
memory,
event handling,
recovery from failures,
trust,
human approval when needed.

The intelligence isn't a single model.
It's the architecture.

Where I Think Travel Tech Is Heading
Over the next few years, I expect travel companies to rely less on dashboards and more on autonomous operational systems.
Instead of logging into ten different platforms every morning, operations teams may simply review:

"Here's what happened overnight.
Here are the issues already resolved.
Here are the three decisions that still require human approval."

That changes the role of operations from reacting to supervising.

I'm Curious What Others Think
If you're building with AI or working in travel operations, I'd love your perspective.
A few questions to start the discussion:

Where do you see the biggest operational bottleneck today?
Would you trust an autonomous agent to handle customer bookings if every action were fully auditable?
What's the biggest challenge you've encountered when moving from AI demos to production systems?

I'm especially interested in hearing from engineers, travel operators, and founders building systems that go beyond chat.
The next generation of AI may not be the one that talks the best.
It may be the one that quietly gets the work done.

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