I use n8n as the entire backend for my SaaS

Most people use n8n to connect Tool A to Tool B.

I use it as the entire backend for a SaaS platform.

Inboundy (inboundy.app) doesn't have a traditional backend. It runs on n8n as an API Gateway — 8 webhook routes, auth handling, auto onboarding, feature delegation, state management via Supabase, and rate-limiting. All in workflows.

The architecture:

Frontend → n8n Webhooks → Services → Supabase

No Express server. No Flask. No microservices. Just workflows.

But the real killer feature isn't the architecture — it's observability.

When a request fails, I see exactly which node broke and why. Instantly. No digging through logs, no reproducing bugs locally. The error is right there in the workflow editor.

With traditional code — especially AI-generated code — you end up with functions calling functions calling functions. Good luck tracing that when something breaks. I've been there. Hours of debugging code I barely understand, written by an LLM that's already forgotten it wrote it.

n8n forces you into a visual structure. You can't hide complexity behind layers of abstraction. Every step is visible. Every failure is traceable.

Is it the "right" way to build a SaaS? Probably not. But it shipped in weeks instead of months, it handles real users every day, and when something breaks — I know exactly where.

Sometimes the best architecture is the one you don't have to maintain.

https://inboundy.app

2 comments