Pipely | Multi-Tenant CRM, HRM and Business Operations Platform (Next.js + Flutter)

Every comparable item on this marketplace is PHP. Most are CodeIgniter, and the volume leader has not been maintained since 2023. Pipely is TypeScript end to end — Next.js App Router and PostgreSQL on the web, Flutter on mobile, one backend behind both.

Run it for your own company, or install it once and give each of your client companies an isolated workspace of their own. Tenant isolation is enforced three ways — a query wrapper, PostgreSQL row-level security, and a session that never trusts an id from a URL — and there are 2,018 tests whose only job is to try to break it.

Seven modules — CRM, projects, invoicing, HRM, support tickets, inventory and accounting — are all built, and all operable from the phone as well as the browser.

CRM

• Contacts, companies and contact channels with a unified activity timeline
• Leads, deals, pipelines and a drag-and-drop kanban board
• Lead conversion that carries the whole history into a contact, company and deal
• A public web-to-lead form, rate-limited, for your marketing site
• SMTP and IMAP email, automation rules, and six reports

Projects

• Projects, tasks, milestones and threaded comments
• A gantt chart drawn in SVG — no charting dependency, no licence to check
• Time tracking that turns logged hours directly into invoice lines

Invoicing

• Estimates with client accept and decline
• Invoices, line items, tax rates and recurring schedules
• Server-rendered PDFs — no headless browser at runtime, so nothing to install and nothing to time out
• Stripe payments with signed webhooks, refunds, credit notes and receipts

HRM

• Employees, departments, designations, employment details and documents
• An org chart built from the reporting line
• Attendance with optional geolocation capture, and leave with an approval flow
• A payroll engine, payslips and HR reports

Support desk

• Ticket queues with manual, least-busy and round-robin assignment rules
• Threaded replies with internal notes your customer never sees
• SLA targets computed on read, so a timer is never stale
• Canned responses and email-to-ticket ingestion
• Customer submission from the client portal

Inventory

• Products with SKUs, categories, cost and sale price, tax class and images
• Multiple warehouses
• An immutable stock ledger — a level is a SUM, never a counter that can drift
• Suppliers and purchase orders with a receive flow
• Stock that moves when an invoice is paid

Accounting

• A chart of accounts and a double-entry journal where a posted entry is reversed, never edited
• Expenses with receipts and client rebilling, and vendor bills
• Automatic posting from invoices, payments, expenses, payroll runs and credit notes
• Five reports: profit and loss, balance sheet, cash flow, expense by category and an account ledger

The client portal

• Your customer signs in, sees their projects and files, accepts an estimate, pays the invoice, downloads the receipt and raises a support ticket — with no member of staff involved
• White-labelled with each tenant’s own colour and logo, with an optional “powered by” credit
• A fourth isolation layer, because two customers of one tenant also need isolating from each other

The Flutter app

• Every module above, on Android and iOS, against the same /api/v1 your own integrations would use
• Biometric lock and secure token storage — refresh tokens never touch shared preferences
• An offline cache for contacts, deals, tasks and today’s schedule
• A sync queue for attendance clock-in, task status, time entries and activity logging
• Invoices, stock and the ledger are online-only on purpose — a figure cached on a phone is a wrong number waiting to be read, and the app says so instead of showing something stale

Multi-tenancy you can audit

Every tenant-owned table carries a non-nullable tenant_id — there are 106 of them — and three independent mechanisms keep one tenant’s data away from another’s:

1. The query wrapper. Every tenant read and write goes through one function that adds the tenant predicate, applies the caller’s permission scope and writes the audit row. Importing the raw database client outside a short declared allowlist fails the linter.
2. Row-level security. Every tenant table has a PostgreSQL policy keyed to a session variable set per transaction. If a query somehow bypasses layer one, the database still returns nothing.
3. The session. Tenant and role come from the authenticated session, never from a URL segment or request body. Changing an id in a URL cannot reach another tenant, because the id in the URL is never trusted.

The isolation suite is 2,018 tests, and part of it runs against a raw database connection with the application’s own wrapper bypassed entirely — so a security claim cannot pass because of the layer above it.