For more than a decade, my day job was not “building software.” It was building homes—managing land deals, drawings, excavations, site teams, channel partners, and collections for multi‑crore residential projects under Amiltus in Bareilly. I lived the friction of Indian real estate end‑to‑end before I ever wrote a single product PRD for Cladbe.
That’s why Cladbe isn’t “a CRM we’re trying to sell into real estate.” It’s a real estate operating system designed by someone who had to survive on the P&L of each tower and row house.
This is the story—and the logic—behind that.
A decade inside Indian real estate, not looking at it from the outside
For 10+ years I was responsible for the full lifecycle:
- Planning & approvals: from unit mix and layouts to amenities and phasing.
- Construction execution: contractors, BOQs, milestones, and site cashflows.
- Sales & distribution: in‑house team plus a rotating army of channel partners.
- Collections & handover: demand letters, penalties, cancellations, refinances, snagging, and post‑handover issues.
On paper, that sounds like four departments. In reality, it was one continuous nervous system held together by Excel, WhatsApp, phone calls, and the founder’s memory.
The problems were always the same:
- Architects designing “award‑winning” layouts that didn’t match what the local market would absorb.
- CRMs that could track leads, but not inventory, receivables, and contracts in one place.
- Portals pushing leads that didn’t know if a unit was actually available.
- Accountants running “secret notebooks” and private sheets for commissions and collections
At some point you realise: this isn’t bad luck. The tools themselves are wrong for how Indian real estate actually works.
Planning: when projects are decided on guesses, not data
Early in my builder journey, design decisions were driven by what felt right:
- “This market loves 3BHKs.”
- “Let’s make the clubhouse bigger, people will like it.”
- “This price per square foot feels competitive.”
Only after launch would the truth hit:
- The 4BHKs were too large for local incomes; they stuck in inventory.
- Parking and amenity mix didn’t match the actual buyer profile.
- Prices and payment plans were not aligned with bank approvals and cashflow needs.
Consulting firms could give us thick reports and slides, but they did not live with the consequences if the unit mix or pricing ladder was wrong. And those recommendations were never wired into a live system that controlled actual inventory, prices, and payment schedules.
That’s why Cladbe’s Studio exists:
- Market research & demand forecasting with hyper‑local data, not generic city stats.
- Unit‑mix planning, amenities strategy, and pricing ladders that are engineered to match sales velocity and revenue targets.
- Payment plan architecture that balances buyer comfort with project cashflows.
And crucially, Studio outputs don’t stay as PDFs—they become live rules inside the OS.
Construction & vendors: everything looked fine… until invoices hit
On site, I saw another version of the same chaos:
- Milestones were marked “done” in WhatsApp groups, not in a central system.
- Vendor invoices came in with vague references: “as per work done”.
- Reconciling PO, work done, and payouts meant chasing three different people and five different sheets.
CRMs had nothing to say here. Generic ERPs were too rigid and never tailored to real estate’s block‑/tower‑/unit‑level complexity.
That’s why the OS goes far beyond “sales pipeline”:
- Contract and milestone management: every contract is linked to projects/blocks/units with clear milestone‑based payout schedules.
- Blind Invoice Verifier: site engineers can verify material and work completion without seeing price, preventing leakage before finance approves payment.
- Unified Payout Engine: all outgoing payments—vendors, commissions, payroll—flow through one audited engine with multi‑level approvals.
This is the kind of structure you only design when you’ve personally sat in reconciliation meetings at 11:30 PM before a bank audit.
Sales & distribution: brokers, double bookings, and “version wars”
On the sales side, the pain was different but related.
A typical day looked like this:
- Three CPs are selling inventory from three different Excel lists.
- One CP promises a unit that’s already given on hold internally.
- Sales team updates their sheet; accountant updates another; portal still shows the unit as “available”.
- Everyone argues over who “had” the lead first and which version of availability is the truth.
CRMs helped us log leads and calls but did not control project + block + unit‑level truth. Portals pushed inquiries but had no stake in the chaos if data was wrong.
The OS had to solve this as a first-class problem:
- Inventory Matrix & Digital Twin: one central, structured record of every project, block, and unit with attributes, documents, and status.
- Real-time availability & statuses: available / hold / blocked / booked across internal team, CPs, and Property.new.
- Stakeholder Prism: controlled visibility so internal teams, specific CP cohorts, and external portals can see different slices of stock without conflict.
On top of that, we needed a Stage that respects how brokers actually work in India:
- Day Zero CP activation with verified inventory via OS.
- Flash Pay payouts (T+24 hours) via nodal/wallet arrangements tied to real transactions, not promises.
- Clear, OS‑logged attribution from the first call/WhatsApp so CPs trust the system.
You don’t design this if you’ve only read about brokers in a pitch deck; you design it after spending years arguing over payout delays and “who brought the customer first”.
Collections & handover: the “boring” part that kills projects
Everyone loves the launch; few people love the three-year construction and collection grind after it.
Here’s what I lived:
- Demand letters generated manually, often late, often inconsistent.
- Interest on delay (IOD) and penalties calculated in ad‑hoc ways, leading to disputes.
- Cancellations, transfers, and refunds tracked in individual files.
At the time of registration and handover, no single place showed:
What’s paid?
What’s pending?
What was waived?
Why?
This is where projects quietly die—not in marketing, but in receivables and trust.
The OS had to treat this like an automation problem, not a “we’ll manage somehow” problem:
Revenue Command Center:
- Automatically generates demand letters based on construction/milestone or time‑linked payment plans.
- Calculates IOD and penalties consistently as per defined logic.
- Issues digital receipts and maintains an audit‑ready ledger for every transaction.
Time Machine audit trail:
Every adjustment, waiver, and refund is logged with context, so nothing depends on who remembers what three years later.
And for buyers, we needed a My Home app:
- One place to see construction photos, timelines, dues, receipts, and snagging tickets.
- A digital record of the life of the asset, not just scattered PDFs and WhatsApp messages.
That level of obsession with collections and handover usually only comes from someone who has watched cashflow curves in boardrooms.
Why a “real estate OS” could only come from the inside
There are very smart SaaS founders and consultants in the market. But most of them:
- Start from what technology can do, not from the ugly constraints of real Indian projects.
- Optimise for one slice: CRM, marketing, or portals—leaving the rest of the lifecycle in spreadsheets.
- Don’t have to carry the weight of “If this goes wrong, the whole project P&L breaks.”
Cladbe’s three pillars exist because the work itself forced that shape:
The Studio – fixes decisions before they hit concrete:
- AI/ML‑aided market research, unit mix, pricing ladders, and GTM strategies directly tied to OS rules.
The OS – becomes the builder’s financial and operational nervous system:
- Inventory Matrix & Prism, Digital EOI & Token Engine, Revenue Command Center, ESS/HR, contracts, unified payouts, omni‑channel CRM.
The Stage – owns the transaction and distribution, not just the search:
- Property.new with OS‑fed verified inventory, Flash Pay for CPs, experience centres, algorithmic matchmaking.
Putting them together wasn’t a branding exercise; it was a survival requirement I discovered one failure at a time.
ace it back to the exact task, team, contract and milestone. CRM analytics cannot look this deep into your projects.
What this means if you’re a builder, broker, or buyer
For builders, it means:
- You’re not buying “yet another CRM” that adds work for your team.
- You’re plugging into a system that was written from the perspective of “How do I protect collections, cashflows, and audit trails for the next three years?”
For channel partners, it means:
- Inventory you see is real, not a stale sheet.
- Payouts are driven by OS logic tied to real transactions, not the mood of the month.
For buyers, it means:
- When you see a project on Property.new, it’s wired to the builder’s own OS.
- When you book and move into My Home, your journey is transparent from token to snagging to community.
Closing thought: Why I’m still wearing both hats
I haven’t “retired” from being a builder. I still think like the person who has to sign off on land, drawings, and project finance—not just cap tables.
That’s deliberate.
The day Cladbe stops feeling like a system I would trust to run my own multi‑crore projects is the day it starts looking like every other SaaS product in the market—nice UI, no real skin in the game.
Until then, the fact that I built homes before I built Cladbe will remain the most important feature of the OS.