Franchise ERP System — 25+ Modules, Multi-Tenant Architecture

When a nationwide equipment rental franchise replaced its 12-year-old SAP rental system with a custom platform, they came to us. 4 months of development, 25+ functional modules, 50+ warehouse integrations — and every shop saves 3 hours per day.

The problem

Our client is a nationwide equipment rental franchise with 50+ locations and 500+ employees. Their serving system was:

• A 12-year-old SAP rental, costing 2.8M HUF/month in license fees
• Individual locations didn't talk to each other — if a machine was in Debrecen and a Győr customer asked for it, nobody knew
• Service workflow was paper-based — service ticket, signature, scan
• POS and warehouse management were in separate systems → 2-3 hours/day per shop lost to "data entry synchronization"

Client's stated goal: 2.8M HUF/month licenses → 0 HUF, plus 3 hours/day/shop savings.

The solution

A multi-tenant ERP platform where each shop runs as its own "tenant" but can see others' warehouses (if permitted). The system comprises 25+ functional modules:

Core modules (phase 1, first 2 months)

• Equipment catalog — every machine, tool, accessory with unique ID
• Rental management — booking, handover, return
• Warehouse management — real-time stock per location
• POS / invoicing — NAV-compatible, Stripe-integrated
• Customer management (CRM-lite) — private and B2B customers

Advanced modules (phase 2, months 3-4)

• Service management — tickets, parts ordering, warranty tracking
• Inter-branch transfer — if a machine is in Debrecen but needed in Győr, 2 clicks
• Financial reports — per-branch and network-wide
• Employee management — attendance, permissions, role-based access
• Sales dashboards — real-time KPI tracking

Architectural decisions

Why PostgreSQL RLS (Row-Level Security) for multi-tenancy?

We evaluated three options:

1. Database-per-tenant — isolated but unscalable with 50+ DBs
2. Schema-per-tenant — still too many schemas at 50+
3. Row-Level Security ← we chose this — single DB, tenant_id on every row, filtering at PostgreSQL level

RLS-filtered queries stay fast (<50ms), and the shop manager only sees their own data; franchise HQ sees everything.

Why PWA and not native mobile?

The service technician works on Android one day, iPhone another. Native = 2× development. PWA: write once, run everywhere, offline-capable (service worker). 30% faster to ship.

Challenge: the switchover from 12-year-old SAP

The client rightly dreaded the switchover. A wrong cutover threatened a month of cash flow at 50 branches.

Our strategy:

1. Dual-run for 2 weeks: SAP and new system running in parallel, every transaction goes into both
2. Daily reconciliation: every morning we compared the two systems' numbers
3. Gradual branch rollout: first week only 3 branches live, then 10-per-wave
4. Dedicated helpdesk from a developer — instant-answer channel

Result — in numbers

• 2.8M HUF/month license → 0 HUF (self-hosting costs 85k HUF/month)
• 3 hours/day saved per branch — nationwide 150 labor hours/day = 3000+ hours/month
• Inter-branch transfer: 2 clicks, 15 minutes → 2 hours reduction with phone calls
• Customer NPS +12 points — faster service

Lessons

1. Multi-tenancy isn't complicated if you choose the right architecture (RLS was simpler for us than schema-per-tenant).
2. Dual-run 2 weeks isn't wasted time — worth the peace of mind. One of the most dreaded steps (go-live) ended up stress-free.
3. The PWA decision saved 30% — we now evaluate this first on every mobile request before native.