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.
Top comments (0)