7 platforms our founders have built independently.

A two-sided B2B platform helping enterprise IT teams discover, evaluate, and shortlist technology solutions through AI-powered recommendations.

Problem

Enterprise IT teams evaluating new platforms rely on analyst reports, RFPs, and word-of-mouth. The signal is slow, fragmented, and biased toward incumbents. A shortlist that should take an afternoon takes weeks, and the reasoning behind it is hard to defend to a procurement committee.

The brief was to build a structured, agentic discovery layer that respects vendor neutrality and produces decisions enterprise buyers can stand behind.

Approach + architecture

Sumyatra is a two-sided platform. On the buyer side, a structured assessment captures requirements, constraints, and context. On the vendor side, a multi-tenant platform lets technology vendors submit and maintain structured profiles under a QA process. Between the two sits an agentic recommendation engine.

The engine doesn't just match keywords. It reasons over the captured requirements against the vendor catalogue, surfaces a ranked shortlist, and explains why each option fits — the signal a procurement committee actually needs. Vector search narrows the candidate set; the agent layer does the structured evaluation on top.

The platform is multi-tenant from the data layer up, with access control separating buyer workspaces from vendor tenancy.

Trade-offs we made

We invested early in vendor-neutrality and explainability rather than raw match volume. A black-box recommender is easy to demo and impossible to defend in a procurement review. We chose the harder path: every recommendation carries its reasoning, because the output has to survive committee scrutiny.

We also built the vendor side under a structured QA process rather than open self-serve submission. It is slower to scale the catalogue, but it keeps recommendation quality defensible — the thing the whole platform depends on.

Outcomes

Sumyatra is live with paying enterprise users, with productized SaaS expansion underway. The architecture is built to onboard vendor partners under a structured QA process and to extend the assessment workflow as new categories are added. Event partner integrations include Google Cloud Next '26.

A multi-module enterprise CRM with a companion headless CMS

Problem

Enterprise CRMs in hospitality and MICE keep running into the same wall. They ship with the features and stop there. The configurability layer, which is the part that decides whether the platform actually fits the business after the first thirty days, is either missing, hardcoded, or so locked that every customisation becomes an engineering ticket. At the same time, the customer-facing surfaces (websites, booking flows, partner portals) live in entirely separate codebases. Their own data layers, their own auth, integration tax every time anything needs to flow back to the CRM.

The brief was to solve both. A CRM with real configurability. A CMS that builds the customer-facing properties. Both designed so the data and actions flow back to the CRM at runtime, not through nightly batch jobs and integration glue.

Approach + architecture

We built the system as two decoupled platforms talking over a public API surface. The CRM is the system-of-record. It holds accounts, contacts, pipelines, activities, events, venues, and the operational data the business runs on. The CMS sits alongside, used to build websites and customer-facing properties. Data and actions flow between them in real time.

The CRM ships eighteen core business modules:

• ·Calendar and activity orchestration with industry-specialised activity types (meetings, calls, trade events, FAM trips), built for the hospitality and MICE businesses the platform predominantly serves.
• ·Account and contact management with parent-child hierarchies, tag-based grouping, and account-type segmentation across corporate, client, and agent categories.
• ·Pipeline management with stage-based opportunity workflows.
• ·Marketing automation.
• ·Product catalogues.
• ·A secure document drive.
• ·A reporting layer with folder organisation, multiple report types, and live-data refresh.
• ·Case management.
• An event management engine in the class of BookMyShow — registration, waiting lists, invitation-only flows, sponsor management, delegate tracking across attended, no-show, declined, and cancelled states, agenda, marketing, QR-coded landing pages, and full revenue tracking.
• ·A venue management module.
• ·A commerce cluster (shop, shop calendar, shop services, shop products) layered into the CRM for businesses that need transactional commerce alongside their operational workflows.
• ·Plus templates, surveys, committees, promo codes, jobs, and employee management.

Configuration substrate

Underneath the modules sits the configuration substrate. A control panel covering automation rules, an object-setup layer that lets enterprise admins extend the data model without code, profiles and granular permissions, a developer console with external-plugin extension points, exchange-rate handling, tax settings, terms and conditions management, email integration, and Xero accounting integration.

Trade-offs we made

A headless, API-coupled architecture was the right call for a platform this size. A monolithic version where CRM and customer-facing site share a codebase would have shipped faster in year one. We chose the architecturally expensive path because the cheap one hits a re-architecture cliff inside three years, and rewriting a platform that already has customers depending on it is the worst kind of work.

The other deliberate call: we built the object-setup layer before any client asked for it. Data-model extensibility without code took months of work that could have gone into features. It's also the reason the platform survived its transition from a one-client build to a multi-tenant product. Most enterprise CRMs die at that transition because their schemas are hardcoded.

Outcomes

The platform is in production today with paying enterprise clients across hospitality, MICE, and venue-focused businesses. Average tenant operates on 1 lakh+ account records, active pipeline workflows, and live event programs. The decoupled architecture has held up. The CMS has evolved independently from the CRM core for years. Modules originally built for single clients (most notably Contact Management) have been productised back into the platform without forking the codebase.

Platform name and client list under NDA.

A multi-tenant CRM built for real estate brokerages — managing leads, property inventories, agent workflows, and customer engagement across distributed sales teams.

Problem

Real estate vendors lose leads they paid to acquire.

Property leads come in from everywhere. Meta Ads campaigns. MagicBricks listings. 99acres. Google Ads. WhatsApp inbound. Walk-in spreadsheets. Each source has its own format, its own latency, its own way of getting lost. A lead that came in on MagicBricks at 11 PM gets seen on Monday morning, by which point the buyer has already toured three other properties with someone else. Multiply that across a brokerage with thirty agents and the leakage is the difference between a profitable month and a flat one.

The CRMs available to Indian real estate vendors either don't integrate with the actual lead sources, or they do but the integrations are brittle, or the lead lifecycle inside the CRM isn't built for how real estate sales actually work — which is mostly WhatsApp, mostly fast, mostly conversational.

The brief was to fix the leak. Build the layer that aggregates leads from every source automatically, gets them in front of an agent fast, and runs the closure conversation where the closure actually happens — on WhatsApp.

Approach + architecture

Recamp ingests leads from multiple sources — Meta Ads, MagicBricks, 99acres, and Google Ads — with Excel imports covering the long tail of walk-ins and partner referrals. Every lead lands in the same pipeline regardless of where it came from.

The CRM then runs the lead lifecycle: capture, deduplication across sources, agent assignment, follow-up tracking, conversion. The closure conversation happens over WhatsApp, with the thread sitting against the lead record so the next agent who picks it up has full context.

The platform is built multi-tenant from the architecture upward. Today, tenants share the platform infrastructure with logical isolation. On the roadmap is a tiered model: a shared-schema tier for smaller vendors who want fast onboarding and a per-tenant schema tier for larger vendors who need full white-label, independent database isolation, and tenant-controlled customisation. The subscription package determines which tier the vendor lands on.

Trade-offs we made

The first call was where to put the WhatsApp integration. The simple version generates click-to-chat links: the agent opens WhatsApp on their phone, has the conversation, and logs the outcome back into Recamp later — if they remember. The harder version flows conversations into the CRM directly so the lead record updates as the conversation progresses. The harder version is correct for real estate, because the conversation is the lead lifecycle in this market. Click-to-chat would have shipped faster and produced data that's perpetually out of sync.

The second call was on the white-label architecture. Single-schema multi-tenant is operationally simpler. Per-tenant schema is what larger vendors actually need — for data isolation, custom field configurations, and the white-label customisation they want to offer their own clients. We designed the data layer to support both from the start rather than retrofit later.

Outcomes

Recamp is live with pilot clients in the Indian real estate sector. The lead ingestion pipeline is running across the major sources. WhatsApp closure is operational. The white-label tiering is being staged for rollout as the vendor mix scales.

A real-time financial information platform aggregating IPO data, subscription tracking, and allocation analytics for Indian retail investors.

In preparation

Case study in preparation.

A vertical SaaS CRM for salon operators — appointments, customer profiles, stylist workflows, and inventory across multi-branch operations.

In preparation

Case study in preparation.

A luxury streetwear commerce platform with editorial product storytelling, drop-style releases, and premium checkout flows.

In preparation

Case study in preparation.

A premium brand experience for a multi-location salon, with service catalog, booking, and content publishing under a consistent design system.

In preparation

Case study in preparation.