PrismBuild: Multi-Tenant Construction ERP
By Codeprism Technologies
A modular-monolith platform that replaces spreadsheets, phone calls and WhatsApp groups with one auditable system for BOQs, work orders, procurement, RA billing and site communication — built with bank-grade multi-tenancy and phone-first login from day one.
Platform
Web & WhatsApp
Duration
~4.5 months (v1, ongoing)
113
Multi-tenant data models
364
Live REST API endpoints
3
Business apps live
Project overview
113 tenant-isolated data models, 364 live API endpoints, and 3 business apps (Project Management, Procurement, Finance) shipped in ~4.5 months on a two-layer multi-tenant architecture.
Platform
Web & WhatsApp
Duration
~4.5 months (v1, ongoing)
Type
PropTech & Construction ERP
Stack
10 technologies
The challenge
Construction and real-estate projects in India routinely run into the crores of rupees, yet day-to-day operations — bills of quantities, work-order approvals, material procurement, running-account (RA) bills — are still coordinated through Excel sheets, personal WhatsApp groups and paper approval registers. Quantities get double-counted between spreadsheets, approvals travel by phone call with no record of who approved what, and procurement moves through disconnected registers for indents, quotations, purchase orders and stock with no single ledger anyone can audit.
BOQ quantities and revisions tracked in spreadsheets with no version history or audit trail
Work-order and RA-bill approvals routed informally, with no accountability chain or record of who signed off
Procurement split across disconnected registers for indents, quotations, purchase orders, GRN and stock, prone to leakage and double-counting
No system enforced who could approve what, on which project, for which company, once a business ran more than one entity or project
Field and vendor communication happened over personal WhatsApp numbers with no company-level record or automation
What we set out to do
- 01
Build genuine multi-tenancy: a shared database that many construction companies can run on side by side without any risk of seeing each other's data
- 02
Model the real Indian-construction workflow, BOQ to Work Order to RA Bill, and Indent to Quotation to PO to GRN to Inventory to Material Issue, as first-class, auditable state machines
- 03
Make phone-first OTP (WhatsApp, SMS or voice) the primary login, with no password required for site and field staff
- 04
Replace fixed roles with a fine-grained, capability-based permission model that works at both the company level and the individual project level
- 05
Bring WhatsApp into the product itself, inbox, templates, campaigns, automations, rather than leaving it as a side channel outside the system of record
- 06
Ship the first three business apps, Project Management, Procurement and Finance, on one contracts-first API that a web frontend today, and a mobile app tomorrow, can both consume
How we solved it
Two-Layer Multi-Tenancy: Prisma + Postgres RLS
Every request seeds an AsyncLocalStorage container with the caller's tenant as soon as it's authenticated. From there, tenancy is enforced twice, independently: a Prisma extension automatically injects tenantId into every query on a scoped model and throws a MissingTenantContextError if none is present, and Postgres Row-Level Security enforces the same boundary again at the database layer, regardless of what the application code does.
Key decision
Defense in depth at the ORM and the database, instead of trusting application-layer scoping alone
Result
All 113 tenant-scoped models are protected twice over; a query missing tenant context fails loudly instead of silently returning another company's rows
One Workflow Engine, Not Six One-Off State Machines
Instead of letting each module invent its own approval logic, a central workflow engine (assertTransition) validates every state change against a registered definition and pins every status to one of five phases (TO_DO / IN_PROGRESS / BLOCKED / DONE / CANCELLED). BOQs, work orders, RA bills, indents, quotations, purchase orders, GRNs, material issues and schedule activities all transition through the same engine.
Key decision
One shared engine driving every approval chain, with attempt-versioned steps so a rejected-and-resubmitted item restarts cleanly at step one
Result
Six-plus approval flows behave consistently and emit the same structured audit_events, instead of six subtly different implementations of approve/reject
BOQ to Work Order to RA Billing, Modeled End-to-End
The BOQ lifecycle (DRAFT to UNDER_REVIEW to APPROVED to SANCTIONED) promotes an approved BOQ into a single active Final BOQ per project. Work orders draw quantity against that Final BOQ and hold it via committedQty; RA bills then cap the cumulative quantity claimed against each work-order line to what the sanctioned BOQ actually allows, the same quantity-holding logic that Indian contractors expect from running-account billing.
Key decision
Quantities are held and released atomically across BOQ, work order and RA bill, rather than reconciled by hand between three separate records
Result
It is structurally impossible to approve a work order, or bill against one, beyond what the sanctioned BOQ allows
Procurement as One Ledger, Not Six Registers
Indent to Quotation to Purchase Order to GRN to Inventory to Material Issue is modeled as a single chain with its own approval gates at Indent, Quotation and PO stage. Stock is mutated in exactly two places, GRN approval and Material Issue, through one inventory ledger with weighted-average rates and a negative-stock guard, rather than being tracked separately per department.
Key decision
A single, append-only inventory ledger as the one source of truth for stock, instead of parallel spreadsheets per store or department
Result
Every unit of material entering or leaving a site store traces back to exactly one GRN line or one Material Issue line
Phone-First Auth and WhatsApp as a Native Channel
Login runs on multi-channel OTP, WhatsApp, SMS or voice, via Meta's Cloud API, MSG91 and Exotel, with anti-enumeration dummy challenges for unknown numbers and a lockout policy on repeated failures. WhatsApp itself is built into the product as a full channel: inbox, contacts, message templates, campaigns and automations, backed by BullMQ queues for delivery and retry, with inbound webhooks verified by HMAC signature and de-duplicated on Meta's own message ID.
Key decision
Treat WhatsApp as a first-class, native channel inside PrismBuild rather than an external integration bolted on afterward
Result
Field staff who have never touched enterprise software can log in and receive updates the exact way they already coordinate work
Measurable impact
113
Tenant-scoped data models covered by RLS
364
REST endpoints across 34 controllers
3
Business apps live end-to-end (of 6 planned)
76
Frontend routes shipped, spanning 23 project-level modules
~4.5 months
From first commit to a live, CI/CD-deployed platform
Tech stack
What we learned
Building PrismBuild in-house meant solving, for ourselves first, the exact governance problems our future customers face: who can see what, who can approve what, and where every rupee and every bag of cement actually goes. Doing that as a disciplined modular monolith, rather than reaching for microservices before there was a reason to, kept a 100,000+ line, two-repo codebase changeable by a small team without losing architectural coherence.
- 01
Enforcing tenant isolation at two independent layers (ORM and database RLS) is worth the upfront cost: it turns an entire class of data leak into a guaranteed exception instead of a hope enforced by code review
- 02
A single, reusable workflow engine for approval chains is cheaper to build once than to reinvent per module, and it's what keeps BOQ, GRN, indent, PO and RA-bill approvals behaviorally consistent across very different domains
- 03
Modeling the domain's real state machines, BOQ to Work Order to RA Bill, Indent to Quotation to PO to GRN, before writing any UI stopped the frontend from inventing shortcuts the backend could never actually guarantee
- 04
A contracts-first API (@prismbuild/contracts) kept a fast-moving Next.js frontend and a fast-moving NestJS backend from drifting apart across 113 shared models
Want a system like this one?
Bring us the problem behind it - the constraint, the load, the deadline. You get an architecture opinion and a cost view from the engineers who built the work on this page, not a sales team.
Prefer we come to you? Fill in the form below.
Tell us where to reach you
Takes under a minute. An engineer reads it, not a lead-scoring tool.
More case studies
Geofencing & Dwell-Time Verification for Field Sales Coverage
View case study AI Agent PipelineBuilding an Autonomous AI Pipeline for SEO-Driven Blog Content
View case study Web Application (SaaS)Building PrismAnalyst: A Privacy-First, Multi-Agent AI Analyst for Business Data
View case studyReady to build something that matters?
We solve problems that don't have Stack Overflow answers. Let's talk.
Book a Discovery Call