What we're building
next.
We place bets on problems the market hasn't fully solved yet — based on patterns we've seen across 7 industries and 9 products. These are the systems we're convinced need to exist. Some are in research. Some are being built. All are serious.
The problems we've chosen to solve
Smart City Parking OS
ResearchTownship parking infrastructure — from spot-matching to full parking management.
The hypothesis
The Parking Marketplace proved that residents will use a trusted platform to match idle parking with seekers. The next problem is broader: townships with 5,000+ residents have no unified parking system. Visitor management, staff parking, EV charging allocation, society subscription parking — all managed separately, none connected.
A Smart City Parking OS would unify all of this: one admin panel, one resident app, one fee structure, connected to society management and security systems.
What's being researched
- Township parking infrastructure mapping (Palava, Lodha, L&T developments)
- Visitor parking management integration with security systems
- EV charging slot allocation and billing
- Society parking subscription management
- Integration path with AI Society Management platform
Business Communication AI
BuildingAI layer for high-volume B2B communication — drafting, summarising, routing, responding.
The hypothesis
JYOTVIRA AI proved the demand for AI-assisted communication at the SME level. The next layer is more ambitious: a context-aware AI that understands your business relationships, drafts communication in your voice, summarises threads, and can triage inbound messages to the right person or workflow.
Indian SMEs and mid-market companies spend disproportionate operational time on email and WhatsApp. This system turns that channel into a managed pipeline — not just a faster drafting tool.
What's being built
- Context-aware reply generation (relationship history, tone matching)
- Thread summarisation for long email or WhatsApp chains
- Inbound triage and routing rules
- Priority flagging for time-sensitive communication
- Team-level communication analytics
Society Technology Platform
ResearchUnified OS for township management — combining three products into one integrated platform.
The hypothesis
We've built three separate systems for housing societies: CHSM for operations, DDMS for digital signage, and a Parking Marketplace. Township management companies and large developers are currently managing these as separate tools with no shared resident identity, no unified reporting, and no integrated billing.
A Society Technology Platform would unify these under a single resident profile and management console — the "OS" for a township's digital infrastructure.
What's being researched
- Unified resident identity across CHSM, DDMS, and Parking
- Township management company admin panel
- Cross-product billing and subscription management
- Developer/builder integration path (new township rollouts)
Contract Intelligence Suite
PilotFrom contract audit to full contract lifecycle management — drafting, negotiation, obligations, renewals.
The hypothesis
The Contract Engine solves the audit problem: it reads existing contracts and surfaces what you should know. The Suite expands this into the full contract lifecycle — drafting new contracts, tracking negotiation changes, managing obligation deadlines, and automating renewal decisions.
For CFOs and legal ops teams managing 50+ vendor relationships, this becomes the command center for every external commitment the company has made.
What's being built
- AI-assisted contract drafting from clause templates
- Negotiation change tracking (redline management)
- Obligation deadline calendar with automated alerts
- Renewal decision dashboard — renew, renegotiate, or exit
- Multi-contract vendor exposure summary
We build what we believe in, not what's trending
Every lab item starts with a deployed product
We don't research in the abstract. Smart City Parking OS grew from running the Parking Marketplace in Palava. Contract Intelligence Suite grew from running the Contract Engine in pilot. The lab is how we decide what the next version of a proven product should become.
We publish the hypothesis, not just the roadmap
Roadmaps are plans. Hypotheses are bets. We show our reasoning so you can evaluate whether the problem we've chosen to solve is actually your problem — and reach out if it is. That's how the best product feedback arrives: before the build, not after.
Early involvement shapes what we build
If a lab initiative matches a real problem you're facing, we want to hear from you before we've committed to the architecture. Early input from practitioners changes what gets built — which is more valuable to you than a feature request after the product ships.
We kill research that doesn't hold under scrutiny
Not everything in the lab becomes a product. If a hypothesis doesn't survive contact with real users, we drop it. The graveyard of cancelled lab items is as important as the shipped products — it tells us where we learned, not where we failed.