Case study background
Enterprise case study · Real estate

When Every Unit, Rupee, and Promise Finally Lived in One Place

How we helped a multi-project developer run sales, site, procurement, marketing, and accounts on one spine—with a consumer app so buyers and partners see the same truth the back office stands behind.

The problem: Meet Karan Sehgal, founder leading a residential developer with active towers across the NCR. His teams were not lazy—work was scattered across Excel, WhatsApp, PDFs, and a patchwork of screens. Marketing ran campaigns; sales chased leads; site and procurement ran on their own clocks—so “real-time KPIs” meant someone typing fast. The board asked what every Indian developer eventually asks: what is sold, what is owed, what is still sellable this week—and the answer lived in six places at once.

The numbers nobody wanted on a slide:

6+
Parallel “systems”
Excel, WhatsApp threads, PDFs, and legacy screens—nothing updated together
48 hr
Lead → inventory lag
marketing and sales saw campaign leads before ops had the same unit map
4.5 hrs
Daily reconciliation
sales ops matching broker sheets to site reality and tower plans
₹2.1Cr
Channel leakage risk
from overlapping holds and informal rate promises in one quarter
62%
Buyer drop-offs
after “we’ll send the payment link by evening” became the norm
3 sites
Different task truths
engineers, contractors, and partners chasing updates in chat, not one schedule

“We weren’t short on effort,” Karan says. “We were short on one place where marketing, sales, site, and accounts pointed at the same units and rupees.” The breaking point was a launch weekend: two channel partners quoted overlapping views of the same inventory; finance heard about it from an angry buyer, not from a dashboard. That was when “track projects, vendors, and KPIs in real time” stopped being a slide and became a mandate.

Enter a deliberate pairing: an ERP-shaped spine for how the developer runs projects, partners, and cash, and a consumer-grade app so buyers see the same truth the back office stands behind—not a portal that quietly forked data.

What we built

One command centre: company, projects, and partner KRIs

  • Role-based dashboards so leadership sees projects, teams, and units—not a slide deck
  • Leads and channel partners on governed inventory: holds, releases, and incentives in one place
  • What’s sellable today is what finance recognises—no parallel “shadow” forecast

Sales & marketing wired to the same funnel truth

  • Pipeline from inquiry to booking with targets and incentive math teams can defend
  • Campaigns, landing forms, and source attribution feeding CRM—no orphan leads
  • Bookings, agreements, and milestone billing aligned to collections

Site ops & procurement that match the plan on the ground

  • Tasks, contractors, and change requests with approvals—timelines stay accountable
  • Material planning, stock, and POs from requirement to GRN with traceability for costing
  • Service providers and vendors scored on delivery—not remembered only in WhatsApp

Accounts, documents, and buyers on one spine

  • Invoices, payables, and payment history tied to project and partner—not spreadsheet islands
  • Agreements and customer comms aligned to inventory state buyers can also see in-app
  • Post-handover service without losing context between legal, CRM, and support

Platform at a glance

Karan’s teams needed the same pattern modern Indian developers expect: a web console for pricing grids, documents, and finance; native-feel mobile for site staff and buyers—one API layer underneath so KPIs stay honest.

Real-time lists and notifications where sales and site can’t afford to refresh ten tabs: bookings, tasks, and feed items update when the record changes—not when someone forwards an email.

Agreements and invoices generated from the same inventory and milestone data finance closes on—so PDFs, the app, and the ledger stop disagreeing at month-end.

Who the product serves

For Karan’s organisation we composed navigation per role: sales sees funnel and inventory; marketing sees campaigns and sources; site sees tasks and change requests; finance sees payables and milestones—without shipping one generic “portal” that satisfies nobody.

Sales & channel

  • Leads, follow-ups, rate lists
  • Available units and incentives

Buyers & residents

  • Projects, applications, deals
  • Payments and support

Builder leadership

  • Company and project control
  • Sales and accounts roll-ups

Site & engineering

  • Tasks, material and change requests
  • Daily execution

Vendors

  • Quotations and orders
  • Fulfilment status

Inventory

  • Stock and material requests
  • Audits

Service partners

  • Tasks, workers, attendance
  • Billing handoffs

Admin

  • Governance and moderation
  • Cross-project visibility

How we rolled it out (without freezing the business)

Delivery was phased so data models and permissions stabilised before wide training—prove the spine, then widen the surface area. That is how we run other enterprise programmes: the business keeps selling while the system catches up to reality.

1
Phase 1

Map how money and units really move

We aligned inventory states, payment milestones, and permissions to how the developer already sold and recognised revenue—before any UI polish. Handoffs to accounting and legacy CRM were scoped so nobody re-keyed the business at go-live.

2
Phase 2

Ship vertical slices people could run

Lead-to-deal flows went end-to-end in staging; mobile personas got their shells early so field feedback landed while back-office grids tightened.

  • Sales and consumer paths on device with real templates
  • Live feeds for tasks and deals so teams stopped polling inboxes
  • Training on real data—not a demo tenant that lied about edge cases
3
Phase 3

Harden, measure, hand over

Load on representative volumes, dashboards checked against finance extracts, and role-by-role training—so go-live was a process upgrade, not a surprise deployment.

Two experiences, one system of record

The operations platform holds inventory, commercial terms, bookings, billing milestones, and partner performance. The consumer application covers discovery, applications, documents, payment schedules, and post-sale service—against the same facts.

Back-office platform

  • Phased inventory: holds, releases, pricing guardrails
  • Booking pipeline through agreement readiness
  • Collections, adjustments, partner settlements
  • Dashboards for sell-through and receivables

Buyer & tenant app

  • Search and shortlists with live availability
  • Application status without opaque email chains
  • Scheduled payments aligned with finance
  • Service and updates after possession

Use cases: how work flows without duplicate entry

These patterns describe how information moves between sales, procurement, site, and finance—without the same unit being typed twice.

Revenue: lead → booking → cash

  • Lead capture and activities feed pipeline reporting
  • Booked units tie to milestones and receivables ageing
  • Finance sees the same status sales commits on site

Procurement: requirement → quote → order

  • Material requirements surface to vendors
  • Quotations convert to orders with traceability
  • Receipts keep inventory honest for costing

Delivery: task → proof → quality

  • Tasks carry assignments, comments, attachments
  • Site evidence lives next to schedule
  • Less leakage to chat and email threads

Outcomes: what changed after go-live

What finally sat in one place

  • Sell-through, receivables, and unsold inventory answered from one spine
  • Partners on governed stock—not parallel “shadow” lists
  • Buyers on a coherent journey—not scattered payment links

What finance stopped fighting

  • Agreements and invoices that match booked terms
  • Month-end trails auditors could follow without heroics
  • Fewer emergency reconciliations after every launch weekend

What we watch in production

  • Reliability and crash signals on web and mobile
  • Predictable sessions for buyers and field staff
  • Analytics on adoption—not just “the app went live”

Where to read more

For how we position ERP for developers and property managers, see ERP for real estate companies. Every shipped narrative and architecture guide lives on case studies.

Real-estate ERP — questions this case study answers

The back-office platform is the system of record for inventory, pricing rules, bookings, collections, and partner performance. The consumer application is the customer-facing surface for discovery, applications, document upload, payment milestones, and service requests—reading and writing through the same APIs so sales, finance, and field teams never reconcile two spreadsheets again.

Developers run phased inventory, channel partner hierarchies, construction-linked milestones, and complex cancellation or transfer rules. Generic ERP can store GL entries but rarely models unit-level inventory and booking velocity the way real-estate teams operate. A domain-shaped data model reduces customization debt and keeps reporting aligned with how leadership actually measures the business.

It means a unit’s status, pricing history, hold rules, booking, agreement, and collection schedule stay connected from first expression of interest through handover. Finance sees receivables ageing tied to real inventory state; sales sees what is actually sellable—not a shadow forecast in email.

Core workflows stay in the operations platform for operational truth, while summaries and journals sync to accounting stacks and optional CRM or marketing tools via APIs and scheduled exports. The goal is one operational spine with controlled handoffs—not duplicate manual entry at every boundary.

Mid-to-large developers and structured channel programs that sell multi-phase projects and need consistent governance across internal teams, brokers, and customers. The payoff is fewer revenue leaks, faster reconciliation, and a branded digital experience buyers expect in competitive markets.

Desk workflows—pricing grids, Gantt views, long reports—fit a large canvas; field staff and buyers need offline-tolerant sessions, camera capture, and push-friendly navigation on phones. Native shells also align with app-store distribution for customers while the operations team stays on a fast-iterating browser deployment.

REST remains the source of truth for transactional writes and reporting exports. WebSocket channels broadcast changes—new tasks, feed items, or status updates—so active screens refresh without polling every list. That pattern keeps servers predictable while the UI feels immediate for sales and site users.