Autor: genbia

Single-tenant is a system for one company. Multi-tenant is a product that several companies use with their data separated, sometimes their brand, and one codebase you operate. The difference is not a Postgres flag. It is whether your business is a project… or software you sell.

Short definition

In multi-tenant each customer (tenant) sees only theirs: users, orders, config, billing. The vendor deploys once, patches once, and charges by usage or plan. In single-tenant each customer can have their instance, their fork, and a versioning nightmare.

If the case is “this clinic and nobody else,” do not force SaaS. If the case is “I will onboard ten similar operations,” the tenant is the product.

Comparison

	One customer (custom)	Multi-tenant SaaS
Fit	Unique, regulated, or rare process	Same flow, many customers
Data	One database, one owner	Isolation per tenant, audits
Billing	Project / hours retainer	Plans, trials, limits
Roadmap	What that contract asks	What scales for everyone
Cost of each new customer	High (another project)	Onboarding, not a rewrite

When yes

• You already sold (or will sell) the same admin to more than one customer.
• The differentiator is the product, not an embedded consultant.
• You need product metrics: activation, churn, usage per tenant.
• You can say no to a custom that breaks the model.

The white-label delivery platform is this pattern: one base, many brands. The WhatsApp CRM too: several teams, one platform.

When no

• One owner and a process that changes every quarter.
• Data-residency rules that require a dedicated instance.
• The first customer demands a fork “because we are special” and there is no second customer.

Then the path is custom software, not a half-SaaS you cannot sell later.

What to design on day one (even if the MVP is thin)

1. Tenant identity. Company, not a loose user.
2. Permissions. Tenant admin vs staff vs you as operator.
3. Limits. What happens if one tenant saturates the API.
4. Backups and deletion. A customer leaves: what is wiped and what stays in logs.
5. Onboarding. Creating a tenant cannot be an engineering ticket every time.

If AI and n8n come in, they hang per tenant (keys, WhatsApp, webhooks). A global workflow that mixes customers is a privacy incident.

How we approach it

We do not start with “FAANG architecture.” We start with: how many tenants in 12 months, and what they must not see of each other? That chooses schema, billing, and the MVP cut.

Schedule a call

GENBIA designs multi-tenant SaaS when the business is the product. If the business is a system for one operation, we build custom and do not pretend it is a marketplace.

Asking “how much is an MVP” without saying what has to work on Friday produces fantasy quotes. A vendor answers a round number. You picture Uber. Six weeks later nobody is aligned.

At Genbia an MVP is the smallest system a real team can operate and measure. It is not a Figma prototype. It is not the full platform with AI, a rider app, e-invoicing, and three “just in case” integrations.

What we are talking about

• Web + API + one role (admin or operations): the cheapest to put in production.
• Web + app (customer or staff): adds stores, QA, and a release cycle.
• Three surfaces (customer, rider, admin): that is a product, not a “generic MVP.” A white-label often beats a from-scratch build.

Custom software starts with discovery. Price follows the cut, not the slogan.

Ranges we use to talk (not a price list)

Order-of-magnitude figures for a project with discovery, production, and handoff. A signed contract can sit outside this if the domain is regulated or the fleet is complex.

Slice	Typical timeline	Usually includes	Usually excludes
Admin + API for one process	6–10 weeks	Login, one happy path, basic logs	App stores, AI, bulk migrations
MVP with one app	8–14 weeks	One mobile role, simple push, admin	Second app, marketplace, full ERP
White-label product (delivery or similar)	Faster start	Branding, environments, what the product already does	Deep custom in month one

If someone quotes “an Uber Eats-like app” at admin-panel money, either the scope is a lie or the product will not reach production.

Published web plans (landings, sites) are not this article. That is a different line: web development.

What inflates the budget without you noticing

1. “While we are here, let’s add…” each extra is a flow, not a sentence.
2. Two apps in the first contract when one + admin already tests the business.
3. “Simple” integrations (ERP, bank, marketplace) that are a project on their own.
4. AI at kickoff. An agent with no statuses and no owner creates tickets, not margin.
5. Brand design + software in the same milestone if the process is not defined yet.

What must be in the first release

• An end-to-end flow (create → assign → close, or the equivalent).
• Permissions: who sees what.
• A production environment, not only staging.
• One metric (own orders, no-show, response time).
• Minimal docs and the repo in your account.

Without that it is not an MVP. It is a demo.

How we scope it with the client

We do not ask for a 40-page RFP on the call. We ask: the process that hurts, the user who suffers it, and what you would accept not having in 90 days. Then we pick build, white label, or “not yet.”

Schedule a call

Ranges are for commercial conversation. The signed scope wins. GENBIA ships software in production; we do not sell loose hours without a cut.

“Build me an app” usually means three different things: mobile access to an admin, an icon on the customer’s phone, or a product in the App Store and Play with notifications and camera. Picking wrong is not a technical footnote. It is this year’s budget and every user’s friction.

What each one is, in operations

A PWA is a site that installs as an icon, works half-offline, and lives in the browser. Useful for catalogs, internal panels, and flows that are already web.

A native app (in our case, Expo / React Native) ships in the stores, uses system push, camera, background GPS, and the permission model users already understand.

It is not “modern vs old.” It is what the phone must do when the network drops or the rider is on the street.

Direct comparison

Criterion	PWA	iOS/Android app
Install	URL + “add to home screen”	Store, review, developer accounts
Push	Limited (especially iOS)	Stable, expected by the user
GPS / camera / background	Fragile or incomplete	Built for fleet, evidence, appointments
Real offline	Page cache	Action queue, sync, photos
Customer trust	“It’s the website”	Brand icon on the phone
Upfront cost	Lower	Higher (stores + QA on two platforms)
Maintenance	One web deploy	Stores + versions + devices

When a PWA is enough

• Users already come from the browser and do not miss a store icon.
• You do not depend on reliable push or continuous tracking.
• The flow is lookup + form, not capturing evidence in the field.
• You want to validate demand in weeks, not launch a mobile product.

If your “app” is really a Next.js site with login, start there. Publishing in stores for vanity delays learning.

When you do need a native app

• A rider, technician, or salesperson uses the phone as a work tool.
• The customer expects “the brand’s app,” not a Safari bookmark.
• Orders, appointments, or deliveries with real-time status.
• Photos, QR, location, or payments that iOS will not give you equally in the browser.

That is iOS and Android app development and the delivery platform: customer, rider, and admin are not the same surface.

The expensive mistake: two products that do not talk

A PWA for the customer and Excel for the rider is not “phase 1.” It is two truths. If you go mobile, the data model (order, assignment, evidence) lives in the backend. Screens hook into it. That is why mobile at Genbia does not start with the icon: it starts from custom software.

How we decide on a call

1. Who opens the app every day (customer, staff, both).
2. What happens if there is no signal for 10 minutes.
3. Whether push is nice-to-have or the operations channel.
4. Whether you must be in the stores for brand or partner policy.

With that we pick PWA, app, or white label. Not a stack because it is trendy.

Schedule a call

GENBIA ships production apps with Expo/React Native and Next.js sites. A PWA is a valid option; it is not a shortcut when the work happens on the street.

There is a moment when Excel, WhatsApp, and three “cheap” tools stop being cheap: the data does not match, the order disappears, and nobody knows which version of the process is real. You do not need more loose automation. You need software that is the system: where the order is born, the customer lives, and operations get measured.

What custom software is (no jargon)

Custom software is a system designed for your model: your statuses, roles, and integrations. It is not a landing page. It is not an n8n workflow hanging off a spreadsheet. It is a product: backend, permissions, history, and a team that can run it when the vendor is not on the call.

At Genbia that can include a web admin, APIs, iOS/Android apps, a delivery platform, or multi-tenant SaaS if you will sell the same product to many customers.

Custom software, generic SaaS, or no-code

Approach	When it fits	It breaks when
Generic SaaS	Standard process, little differentiation	The vendor does not have your flow and you pay for workarounds forever
No-code / n8n only	Connecting what already runs	The “system” is a graph nobody documents
Custom software	The process **is** the business	You build without discovery or an internal owner

Automation and AI come after: on top of the software. If the core lives in chats, an agent only speeds up the mess.

Signs it is time to build

• You copy the same process across three tools and still paste by hand.
• The customer or rider does not see the same status as operations.
• You want your own channel (brand, data, margin) and the marketplace keeps the relationship.
• A SaaS asks you to “adapt to them” on what makes you different.
• You need the code to be your asset, with a repo and a handoff.

If volume is still a trial, start with a scoped MVP — not a rewrite of the whole company.

What we ask in discovery (so we do not invent a monster)

1. Who uses what. Owner, operations, end customer, rider, admin.
2. Where the data is born. Order, lead, appointment, dispatch.
3. What cannot fail. Payments, proof of delivery, permissions, audit.
4. What it integrates with. ERP, payments, WhatsApp Cloud API, the spreadsheet that still runs the show.
5. A metric for the first 8–14 weeks. Not “digital transformation.” One number.

The deliverable is not a deck. It is a product slice you can put in production.

How we build it at Genbia

On custom software the order is system → interfaces → integrations. Typical stack: Next.js, APIs, PostgreSQL, Expo apps when there is mobile. WhatsApp and n8n when the product already has a backend for webhooks.

We do not sell loose “programming hours.” We sell a system your team operates, with documentation and the code in your repository.

Expensive mistakes we see often

• Starting with a pretty app and leaving the data model for “later.”
• Copying Uber/DoorDash in the first contract.
• Adding an AI agent before you have statuses and logs.
• Not naming who owns the product inside the company.

How to start

If you already know the bottleneck is the system — not a campaign or a brochure site — book a 30-minute call. We will say whether an MVP, a white-label product (delivery, CRM), or a custom build fits. No purchase commitment.

Schedule a call

GENBIA builds custom software, apps, and production platforms. WhatsApp, n8n, and AI ship when the product needs them.

Running deliveries without infrastructure feels “cheap” until it does not: orders on WhatsApp, addresses in Excel, the rider calling in, and nobody sure what state the package is in. Small businesses and courier shops that start this way are not looking for “a pretty app.” They want control — knowing what was ordered, who was assigned, and what evidence proves delivery — without the permanent marketplace tax or inventing an Uber Eats clone from scratch.

What companies without an app are actually looking for

In discovery with small operators (dark kitchens, local couriers, retail with own dispatch, pharmacies, B2B between locations) the pattern repeats:

1. Improvised order channel. WhatsApp, Instagram, or phone. Works at 5 deliveries a day; breaks at 30.
2. Zero operational visibility. No map, filters, or history. If the rider does not reply, the order “disappears.”
3. Customer data you do not own. On marketplace apps the platform keeps the relationship and takes a high commission (typical LatAm/US ranges often land around ~20–35% of ticket, plus boost and packaging). Fine for demand acquisition; burns margin if it is your only channel.
4. Fear of “building an app.” They equate own software with years, infinite budget, and a prototype that never reaches production.
5. Need for three roles, not one screen. Who creates the shipment, who assigns, who delivers. Missing one and you are back to Excel.

In their words: “something with my brand,” “the rider sees the order on the phone,” “I see the map,” “delivery photo,” “no per-order commission.”

Signs WhatsApp + Excel is no longer enough

• You lose orders between chats or duplicate them.
• You cannot tell the customer where it is without calling the rider.
• You mix own and external fleet with no single assignment record.
• You want to grow to another zone or vertical and the process does not scale.
• You already pay marketplace commissions and want an owned channel for recurring customers (even if the marketplace stays for acquisition).

If your case is “five friend deliveries a week,” you may not need a platform yet. If your case is “this is the business,” you do.

Own app, closed SaaS, or white label: what fits

Approach	When it fits	Typical risk
Stay on WhatsApp / spreadsheets	Very low volume, early validation	Chaos, no audit trail, impossible to scale
Marketplace only	You need external demand now	Commission, weak customer control, dependency
Closed logistics SaaS	You want to operate fast under the vendor’s rules	Brand, data, and customization limits
White label / product base + partner	You want **your brand**, three surfaces (customer, admin, rider), and a maintainable asset	Upfront investment; in exchange for control
100% greenfield app with no reference	Very unusual requirements or a large in-house team	Timeline, cost, and risk of never reaching production

For a company starting without infrastructure, the sweet spot is usually: do not reinvent the last-mile data model, but do adapt brand, rates, statuses, and vocabulary (packages ≠ menus).

What a last-mile platform must include (real checklist)

Ignore the “next Uber” pitch. Check whether the system covers the full cycle:

1. Order intake (customer app or panel)

Pickup and drop-off addresses, shipment data, package photo, initial status in a database — not in a chat that gets archived.

2. Operations (admin panel)

Lists with filters and date ranges, map, assign or reassign rider with a timestamp, customer finances when needed, queue of new rider applications.

3. Street execution (rider app)

Assigned / in progress / delivered orders, location, availability (go online/offline), typed photo evidence.

4. One source of truth

The same data model across all three surfaces. No improvised API between three different vendors.

5. Shipment identification

QR or another ID so customer and ops talk about the same order. (Automatic rider scan: only if it is in scope — do not assume it.)

6. Production-ready

Role-based auth, secure photo storage, store builds, rules for who sees what. A demo is not an operation.

How Genbia solves this (Golleva reference)

Genbia implements delivery / last-mile platforms under your brand. The on-screen reference is Golleva: three apps (web admin, customer app, rider app) on the same Postgres and Supabase (Auth, Storage, Realtime).

Product detail and real screenshots: Delivery platform white label · Genbia.

Order flow (the one that matters)

1. Customer creates the order — addresses, data, photo, initial status.
2. Admin operates and assigns — filters, map, rider change with traceability.
3. Rider executes — active orders, location, evidence in Storage.
4. Everything is audited — one database, role policies, near-real-time updates where wired.

Who it serves (not only food)

• Urban messaging and parcel courier.
• Retail / e-commerce with own or mixed fleet.
• Dark kitchens or food delivery under your brand.
• Pharmacies, documents, B2B between locations.
• Companies mixing employee riders and contractors under the same rules.

Stack (for teams evaluating maintainability)

• Admin: React, TypeScript, Vite, Leaflet maps, Supabase JS.
• Apps: Expo / React Native (customer and rider).
• Backend: Supabase (Postgres + RLS + Storage + Realtime); Edge Functions for payments or other integrations.

We do not sell “a generic food template.” We start from a proven base and adapt branding, naming, and business rules to your vertical and country.

Own delivery vs marketplace: decide with numbers in mind

You do not need a perfect spreadsheet. Useful questions:

• What % of orders already come from customers who would find you without the marketplace?
• How much margin do you lose today to commission + in-app advertising?
• Can you run 1–N own riders or a governable external network?
• Does the end customer need to see your brand on tracking?

Practical rule we use in conversation: the marketplace can stay as an acquisition channel; the owned channel protects margin and relationship. A white-label platform is the operational layer of that channel — not a magical marketing replacement.

Mistakes SMBs make when “getting an app”

• Asking for “an app” when you actually need three surfaces + a backend.
• Starting with icon design and forgetting assignment, evidence, and statuses.
• Hiring a freelancer who ships screens with no data model or roles.
• Copying a food Uber Eats when the business is parcels (different vocabulary and statuses).
• Assuming the QR “already scans automatically” without putting it in scope.
• Skipping handoff: without transfer, you are stuck with whoever “understands the mess.”

How to start with Genbia

1. Book a short discovery meeting.
2. Bring your current flow (even if it is WhatsApp) and 1–2 measurable pains: lost orders, assignment time, claims without evidence.
3. We assess whether the Golleva / delivery-platform base fits, what gets rethemed, and what is custom (payments, OMS/ERP, QR scan, fleet telematics, etc.).
4. We leave with a scoped path to production, not a trade-show prototype.

Reach us from Contact, WhatsApp, or [email protected]. The service page with screenshots and FAQ is at genbia.com/delivery-platform.

Genbia — technology consulting: software, automation, and AI for companies that want to operate with less friction. Golleva is a last-mile product reference in the Genbia ecosystem; Uber Eats, DoorDash, and related brands belong to their respective owners. Genbia is not affiliated with those platforms; we implement white-label software and integrations per agreed scope.

If your team still copies data between Excel, the CRM, WhatsApp, and the ERP, the problem is not “not enough people” — it is the lack of a system that moves information for you. That is what n8n is for. At Genbia we use it as an automation engine in real projects — not lab demos — so operations, sales, and support stop depending on copy-paste.

What n8n is (without useless jargon)

n8n is a workflow automation platform. You connect systems (CRM, ERP, WhatsApp Business Cloud API, Google Sheets, databases, custom APIs) and define rules: when X happens, do Y, with Z conditions and a record of what occurred.

Unlike a one-off script or an isolated “bot,” n8n gives you:

• A visual canvas of nodes (easy to review with business stakeholders).
• Real logic: conditions, loops, errors, retries, branches.
• Self-hosting (your data on your infrastructure) or cloud.
• Code when you need it, without rewriting the whole stack.

It is not magic. It is orchestration: value lives in which processes you automate and how you operate them after go-live.

Why companies adopt it now

Three reasons show up again and again in Genbia discovery calls:

1. Tools that do not talk to each other. An order arrives on WhatsApp, gets logged in a sheet, invoiced in another system, and the customer asks for status on a fourth channel. Every hop is error and delay.
2. Cost of not automating. Weekly hours of skilled people on repetitive work; cooling leads; stock or appointments out of sync.
3. Limits of generic no-code. Zapier or Make work for simple integrations. When business logic, high volume, self-hosting, or data governance appear, many companies hit a wall or overpay.

n8n fits when you want control (who sees what, where it runs, how you audit) and depth (not only “if a new row appears, send an email”).

What n8n is NOT (clear expectations)

• It does not replace a full ERP.
• It does not “implement itself” without a process owner in your company.
• It is not a marketing chatbot: it can feed AI agents, but prompt design, tools, and guardrails are separate work (which we also do).

If someone sells “we install n8n and the chaos ends” without mapping processes, be skeptical. Software only accelerates a well-defined process — or multiplies a bad one.

Real patterns Genbia implements with n8n

These are patterns we repeat across markets. Names change; the pain does not.

1. Lead → CRM → follow-up without drop-offs

A web form or WhatsApp message creates the lead, scores priority, notifies the owner (Telegram, email, or Chatwoot), and schedules the next follow-up. On Genbia’s own site, the contact form feeds the CRM through n8n — no intermediate spreadsheet.

What you gain: fewer lost leads, source traceability, and measurable time-to-first-response.

2. Operations across CRM, ERP, and sheets

Customer onboarding, order status updates, payment reconciliation, or nightly sync between legacy systems and modern tools. n8n acts as a light “bus” while you migrate or coexist with what you already have.

What you gain: one operational source of truth, fewer inconsistencies between teams.

3. Official WhatsApp (Cloud API) + automation

Templates, human routing, alerts, and ticket close. Genbia implements WhatsApp Business Platform as a Tech Provider / Cloud API: lower risk than unofficial integrations, aligned with Meta policies.

What you gain: conversation on the customer’s channel, with records and without constant fear of number bans.

4. AI agents with real actions

The model does not only “chat”: it checks stock, opens a ticket, books a visit, or triggers an n8n flow with validations. Guardrails, logs, and handoff to a person when the case leaves the script.

What you gain: faster support and pre-sales, without leaving operations on blind autopilot.

5. Reporting and alerts

Every morning (or when a threshold is crossed) a flow builds the summary: orders, SLAs, integration failures, pipeline. It lands where the team already looks (email, Slack, Telegram).

What you gain: visibility without someone losing an hour building the spreadsheet.

How Genbia helps (method, not speech)

We do not deliver “a pretty workflow in screenshots.” We deliver automation in production.

1. Process discovery

We identify what hurts, what repeats, and where ROI sits. We prioritize quick wins (weeks, not years) over big-bang programs.

2. Architecture and integrations

We define source/destination systems, auth, error handling, idempotency (avoid duplicates), and where n8n lives (self-hosted or cloud). If you already have CRM, ERP, or WhatsApp, we integrate — we do not force a full stack migration overnight.

3. Implementation in n8n

Readable, versionable, documented flows. Credentials out of the improvised canvas. Test environments when risk requires it.

4. Production and observability

Failure monitoring, retries, alerts to the right team. You know what happened and when — critical for operations and compliance.

5. Handoff and evolution

Documentation, handoff session, and optionally a squad or hour bank to iterate. The goal is a system that is your asset, not a black box owned by the vendor.

Indicative timelines (always scope-dependent): automation quick wins in 4–8 weeks; projects with more integrations and AI in larger ranges defined in the proposal.

n8n vs “we’ll do it with a freelancer / Zapier”

Approach	Typical outcome	Risk
Lone freelancer	A flow that “works” until the API changes	No docs, no owner, no monitoring
Zapier/Make only	Fast simple integrations	Per-task cost, logic limits, data outside your control
Genbia + n8n	Production flows integrated into your stack	Upfront investment; in exchange for a maintainable asset

If your case is “notify me when there is a new row in Sheets,” you may not need a Genbia project. If your case is “orders, WhatsApp, billing, and CRM must talk without burning out my team,” you do.

Signals you should talk to us

• Your operation lives in WhatsApp + Excel and already hurts to scale.
• You lose leads or orders across channels.
• You tried no-code and hit logic or volume limits.
• You want official WhatsApp (Cloud API), not a hack.
• You need a partner that joins software + automation + AI, not just a website.

How to start

1. Book a short discovery call.
2. Bring 1–2 processes that cost you the most time or errors.
3. Leave with a quick-win map and a scoped proposal.

You can reach us from Contact, WhatsApp, or [email protected]. If you already use n8n and it is “half done,” we also audit and stabilize what exists.

Genbia — technology consulting: software, automation, and AI for companies that want to operate with less friction. n8n is a trademark of n8n GmbH; Genbia is not officially affiliated; we implement, maintain, and operate best practices on the platform.