What is Vrida
Vrida is a generic, multi-tenant retail ERP and point-of-sale platform. It is designed to work across retail business types, with the retail plant nursery as its first and reference vertical. Nurseries drive concrete requirements and the initial go-to-market, but the product's architecture treats them as a reference customer, not as the target definition: no business-type assumption is baked into the foundation. Vertical-specific needs are handled through flexible mechanisms — an item_type discriminator plus JSONB attributes, generic reusable tables, and optional vertical add-on modules beside the foundation — never through business-specific columns on shared schemas.
The platform is AI-native. AI is not a separate feature or a bolt-on — it is woven as a cross-cutting service layer through every module, with consistent authority controls, an execution ledger, and graceful fallback to deterministic behavior when AI is off or unavailable.
Who it's for
Vrida is designed for growth-stage retail businesses. The anchor profile is a mid-size retail operation: roughly $500K–$5M in revenue, 800–3,000 SKUs, 5–20 staff, operating from a single location with a realistic path to multiple sites. In the reference vertical, this maps to an established independent retail nursery.
The platform is usable across the size spectrum — from owner-operated single-location shops to multi-location growing businesses — and the tiering model is designed to accommodate that range without forcing premature upgrades.
The customer mix in the reference profile skews retail-first: roughly 70% walk-in retail, 20% contractor and B2B, 10% commercial and institutional. Vrida's feature set reflects that mix: a full POS, a customer relationship and charge-account layer, and purchasing that handles both reactive reorder and vendor relationship management.
Tiers
Three tiers: Starter, Pro, and Enterprise.
The key design principle is that tiers gate volume, not capability. A Starter tenant and an Enterprise tenant run the same codebase and have access to the same features; what changes across tiers is the maximum number of SKUs, users, and sites the account may use. Tier limits are enforced at the application layer through feature flags and usage metering — there is no artificial feature-gating to motivate upgrades. The goal is for a small business to get a complete product, and for a growing business to scale into higher tiers as their operational footprint grows, not because a capability has been withheld.
Enterprise targets feature parity with established mid-market ERP competitors, with multi-location management, Enterprise-tier integrations, and API access.
What it supports
Foundation and service layer
These schemas underpin every module. They handle platform-level concerns and are never business-specific.
| Schema | What it does |
|---|---|
platform |
The control plane — tenant identity, SaaS subscription and billing state, legal agreements, usage metering, onboarding, and entitlements. The authoritative source for what each tenant is allowed to do. |
identity |
Authorization layer — staff users, tenant membership, roles and permissions, site-level access, SSO configuration, and support-access grants. Supabase Auth handles authentication; Identity owns authorization. |
payments |
Merchant Stripe Connect — customer payments, Terminal integration, payouts, refunds, and the Stripe event log. All Stripe interaction passes through one PaymentsService. |
integrations |
External-connector runtime — connectors, OAuth credential rotation, sync runs, provider call logs, inbound and outbound webhooks, and field mapping. Connector configuration lives in Admin; execution lives here. |
ai |
AI onboarding import pipeline and the Bedrock call log. AI features are a service layer over existing data; all AI actions are human-in-the-loop, enforced at the database level. |
files |
File metadata registry over Cloudflare R2 — metadata, visibility tiers, fine-grained access grants, and storage usage quotas. R2 holds bytes; Files holds metadata. |
search |
Postgres-native full-text and trigram search across key entities — delivered as additive search vectors on source tables, not as a separate search service. |
shared |
Non-tenant global reference data — countries, states, currencies, units of measure. |
Business capabilities
The operational modules that make up the daily ERP surface.
| Schema | What it does |
|---|---|
inventory |
The item catalog — items, variants, stock levels, lot tracking, kits, and cycle counts. Owns the item as the universal product record; vertical-specific attributes live in JSONB, not in extra columns. |
pricing |
Price lists, per-variant rules, customer and group assignments, quantity breaks, and dated promotional pricing. Layers on top of the inventory base price. |
pos |
In-store transactions, offline-first — sales, tenders, refunds, registers, gift cards, store credit, layaway, and sync conflict resolution. The only module with true offline-first capability. |
orders |
Quotes, orders, special orders, and preorders; deposits and installment schedules; light fulfillment tracking. Orders link to POS sales rather than converting into them. |
purchasing |
Vendors, purchase orders, receiving, vendor invoices and bills, vendor returns, and landed cost allocation. Calls InventoryService to register received stock. |
billing |
Merchant-side accounts receivable and payable — charge accounts, customer credit, statements, and vendor bill payments. Distinct from SaaS subscription billing in platform. |
crm |
Customers (individual and business), contacts, addresses, customer groups, notes, merge audit, consent log, and tax certificates. |
multi_loc |
The site concept — a named physical business location. Defines the site_id foreign key referenced across every transactional schema. |
admin |
Tenant configuration — settings, branding, tax configuration via Stripe Tax, and integration and webhook configuration. |
audit |
Cross-cutting integrity-chained audit log and compliance workflow — GDPR/CCPA data subject requests, breach incident records, data processing agreements, subprocessor registry, and audit exports. |
notifications |
Event-driven delivery orchestrator — templates, notification routing, delivery attempts, in-app inbox, preference management, journeys, campaigns, and two-way SMS. |
reporting |
Operational BI — financial snapshot tables, materialized views, and a service-layer analytics abstraction. Terminal module: reads from every other schema; nothing depends on it. |
Consumer layer
A distinct product surface built on top of the merchant core, supporting direct consumer relationships across businesses.
| Schema | What it does |
|---|---|
consumer |
A platform-level consumer identity — a person account that spans multiple tenants. A consumer can have a relationship with multiple businesses on the platform without creating a separate account per business. |
rewards |
Per-business loyalty — points, tiers, earning rules, a redemption catalog, and a ledger. Tenant-scoped; consumers earn and redeem within each business separately. |
offers |
Business-issued discount and promotional offers — offer definition, codes, assignment lifecycle, and append-only redemption records. Settlement feeds back to the platform. |
How it's built
Clients. A Flutter mobile app (phone-primary, tablet-secondary) with offline support via SQLite/Drift, and a web app. Both share one backend API.
Backend. NestJS on AWS App Runner, with PostgreSQL via Supabase and Drizzle as the ORM.
Multi-tenancy. All tenant data lives in a shared Postgres database. Row-Level Security policies enforce isolation: a session variable carries the current tenant ID, and RLS policies ensure no query can cross tenant boundaries. Schemas are organized per module; modules communicate through typed service-class APIs and never query each other's tables directly.
Platform services.
| Service | Purpose |
|---|---|
| Stripe | Payments — all interaction through one PaymentsService |
| AWS Bedrock (Claude Haiku 4.5) | AI — all Bedrock interaction through one AIService |
| Cloudflare R2 + CDN | File storage and delivery |
| Supabase Realtime | Live data subscriptions |
| Resend | Transactional email |
Foundational principles.
- Soft delete everywhere. Rows are never hard-deleted;
deleted_atmarks removal. This preserves referential integrity, supports audit reconstruction, and eliminates a class of irreversible data-loss bugs. - Audit log from day one. A cross-cutting integrity-chained audit log captures every consequential action across the system. Compliance workflows (GDPR/CCPA data subject requests, breach records) are built on it.
- AI-native architecture. AI is not added to existing flows after the fact — it is designed as a cross-cutting capability layer from the start, with explicit authority levels, an execution ledger, and deterministic fallback behavior for every feature when AI is off or unavailable.