Forty-plus programs across our founders' careers.

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.

Problem

Hospitality groups run on Property Management Systems. The PMS holds the operational truth: bookings, occupancy, rate plans, guest profiles. Extracting intelligence from it at the group level is harder than it sounds.

Data formats differ between PMS vendors. Feeds drop intermittently. Time zones, currencies, and property naming conventions vary across the portfolio. The people who actually need the data, CEOs and revenue heads and operations leadership, need dashboards that load in seconds during a meeting. Not OLAP queries that take a minute to return.

The brief was to integrate the CRM platform from Program 1 with the group's PMS environment, ingest booking and operational data at scale, and build the analytics layer that revenue and executive teams could use day-to-day.

Approach + architecture

We built the integration as a resilient ingest pipeline, designed for the messy realities of hospitality data. Heterogeneous PMS vendor formats. Intermittent feed reliability. Multi-property, multi-currency normalisation. The ingest layer handles 1 million+ booking records per quarter, normalises across vendors and properties, and feeds a structured analytics tier on top.

The analytics tier was built around one principle. Pre-aggregate at the cardinalities that matter. The dashboards a CEO looks at (property-level performance, seasonal demand, occupancy and rate trends, year-over-year comparisons, source-channel breakdowns) answer questions in milliseconds. They don't run real-time queries against the warehouse. Behind that is a deliberate choice about what to compute upfront and what to compute on demand. Get the boundary wrong and the dashboard either loads slowly or shows stale numbers.

Trade-offs we made

Pre-aggregation costs storage and adds complexity to the pipeline. When a booking record updates upstream, every aggregate that touches it has to refresh. The alternative is compute everything on demand, which costs query time, which costs executive patience. We optimised for executive patience. A dashboard that loads in 300 milliseconds gets used. A dashboard that loads in eight seconds gets closed and replaced with a spreadsheet.

The second call: we built feed-failure resilience into the ingest layer from day one. PMS feeds drop. When they do, the analytics tier either silently shows stale data or surfaces the gap visibly. We chose to surface it. Explicit “data current as of X” timestamps. Visible alerts when ingest falls behind. Operators trust dashboards that admit their own limits.

Outcomes

The integration runs in production. The dashboards are consumed by CEO-level and operations leadership across the hospitality group. Revenue teams use them for daily rate and inventory decisions. Hospitality remains one of the verticals the team has operated in most deeply.

Problem

Dynamic pricing in hospitality has a particular failure mode. Model-driven pricing systems occasionally surface a number the revenue manager cannot defend in a Monday-morning meeting. The model says €847 for a room that historically sold at €310. There's usually a plausible reason: demand spike, event nearby, low remaining inventory. But if the revenue manager can't explain what the model saw, the system loses the team's trust within weeks. Rate decisions go back to spreadsheets.

The brief was to build pricing the revenue team would actually use.

Approach + architecture

We built a rule-augmented engine, not a model-only system. The architecture processes historical booking trends, seasonal demand patterns, occupancy signals, and business rules in real time. Within that structure:

• ·The model contributes signal. It surfaces patterns the team would miss.
• ·Rules govern guardrails. Minimum and maximum price bands, rate-plan-specific constraints, channel-specific logic.
• ·Revenue managers retain override authority. They can accept the model's suggestion, override within rules, or override entirely with a reason logged.

Trade-offs we made

Pure ML pricing would have produced better revenue numbers in offline backtests. We chose the hybrid because production deployment is the only thing that matters, and production deployment requires the revenue team to keep the system running. Predictability and explainability are features here, not constraints.

The second call: rule complexity. Pricing rules in hospitality multiply quickly. Channel-specific, segment-specific, season-specific, property-specific. We exposed rule management to revenue managers themselves rather than gate it behind engineering tickets. That shifted complexity from engineering to operations, which is the right place for it. Engineering shouldn't be on the critical path for a rate adjustment.

Outcomes

The engine runs in production. Revenue teams use it for daily pricing decisions. The override mechanism is used, which is itself a sign the system is being engaged with seriously rather than ignored.

Problem

Most enterprise AI in lending is a chatbot bolted onto a credit application form. The agent handles greeting and FAQ, then hands off to a traditional rule-based workflow for anything that matters.

The brief here was different. Build a lending platform where AI agents own the actual journey. Qualification, document intelligence, recommendation, optimisation, onboarding. Not just the front door.

The constraints came from the domain. This is regulated lending. Audit trails are not optional. Decision explainability is not optional. Hallucination tolerance on numbers is approximately zero. Human-in-the-loop fallback is required at every step that touches a credit decision.

Approach + architecture

We built the platform around cooperating agents, each with a defined scope:

• ·A lead qualification agent handles initial customer interaction, surfaces eligibility signals, and routes the application.
• ·A document intelligence layer extracts structured data from uploaded KYC and financial paperwork.
• ·A bank and product recommendation agent matches the customer profile to lending products.
• ·An interest optimisation agent surfaces the best available rate within constraints.
• ·An application orchestration layer runs the workflow through to onboarding.

Trade-offs we made

The agents are not autonomous in the sense of making credit decisions unilaterally. They surface, structure, and propose. The credit decision itself stays under human review, with the full agent reasoning trail attached.

The biggest decision was where to put the model and where to put the rules. We pushed the model deep into the interaction and extraction layers, where probabilistic reasoning is genuinely useful. We kept the rules in the decision layer, where deterministic logic is non-negotiable. The temptation in any AI lending build is to let the model creep into the decision layer. The demos are spectacular when it does. Regulated lending workflows fail in audit when the answer to “why was this loan rejected” is “the model said so.”

The second call: we logged everything, including the model's intermediate reasoning. Storage cost is real. The trade-off is auditability. When the regulator asks how a particular application was processed, we can replay the full agent reasoning trail. That capability was the precondition for the platform to ship to a regulated environment at all.

Outcomes

The platform runs in production. This is the program we point to when the question is “have you actually shipped AI into a regulated enterprise workflow?”

Problem

Industrial IoT in manufacturing has a recurring pattern. Clean dashboards get designed by software people. Then they get deployed into factory floors where the actual problem is intermittent connectivity, time-series data volume, sensor reliability, and field engineers who need useful information in their hand while standing next to a compressor. Not a beautiful dashboard at headquarters.

The brief was to build a remote monitoring and operational intelligence platform for Kirloskar Compressors that worked in the environment it actually had to operate in.

Approach + architecture

The platform is mobile-first by deliberate choice. Equipment status, power consumption analytics, operational alerts, and historical performance data flow through an interface designed for field engineers and operations leads, not desktop dashboards. Behind the interface, the data architecture handles the realities of industrial deployments. Sensor feeds with variable reliability. Time-series data at scale. Alerting logic that separates signal from noise.

Trade-offs we made

Mobile-first cost design time and engineering complexity. A desktop-first platform with a mobile companion would have shipped faster. We chose mobile-first because the user's hands are on the equipment. A platform the field engineer actually uses is worth more than one the operations VP admires.

Outcomes

The platform runs in production. Worth flagging: this is the only program on this page named openly. Most prior work sits under NDA. Kirloskar gave permission to discuss this delivery, and we do, because it's representative of the team's industrial IoT depth.

Problem

Regulated fintech in tier-1 Indian banking is a different sport from consumer fintech. Compliance is structural, not bolted on. Transaction integrity is not an SLA, it's an obligation. Availability requirements come from the regulator. The engineering teams operate inside review processes that consumer fintech startups would find unrecognisable.

The brief, repeated across multiple programs in this category over the team's careers, was to build payment, wallet, card, and UPI capabilities inside that environment. Not the demo version. The version that actually ships through bank compliance.

Approach + architecture

Specific platforms sit under NDA. Categorically, the work spans digital payments, wallet management, card transactions, and UPI workflows. Built to the compliance, availability, and transaction-integrity standards of tier-1 Indian banking environments.

Outcomes

Programs in this category have shipped through bank compliance and run in production. Specifics are NDA-protected. Deeper discussion is available under NDA.