Back to Blog
Company Founding Story Product Vision

Why We Built Centralyse: The Problem We Kept Running Into

Rachit Kataria 7 min read
Abstract origin concept showing a problem in relationship networks being identified

Before Marta and I wrote a single line of code for Centralyse, we had both independently spent years bumping into the same problem. It came up in different contexts, different industries, different company sizes. But the shape of it was always the same: a deal that looked healthy on paper went dark because of a relationship shift that nobody had tracked.

I want to explain what we saw, because I think it gets at something most sales tools still don't address well.

The problem I kept hitting in sales

For several years I worked in B2B sales and sales operations, running deals and building process across a few different companies. The work I did involved complex, multi-contact deals. Multiple stakeholders, long cycles, six-figure contract values.

After enough of those deals, you start to notice the pattern. The CRM is never actually telling you what's happening inside an account. It's a log of what already happened. Your notes, meeting outcomes, email status. It reflects your activity, not the account's internal reality.

The problem is that the internal reality changes constantly. A champion gets reorganized. A budget cycle shifts. A new VP comes in and resets priorities. An evaluator who seemed peripheral is actually the one who controls budget sign-off. All of this happens between your last touchpoint and your next call, and your CRM doesn't know any of it.

I started building workarounds. Spreadsheets that mapped org charts. Manual contact scoring systems. Processes to track when I last talked to each key contact and flag anything over two weeks. These helped. They also took several hours a week to maintain and depended entirely on me remembering to update them correctly.

What Marta was seeing on the infrastructure side

Marta spent years building real-time data sync and integration infrastructure at enterprise software companies. Her version of the same problem was different: she kept watching CRM data go stale. Not because the systems were bad, but because the data was fundamentally batch-oriented. Sync ran once a day, or once a week. Contact records reflected what a rep logged, not what was actually happening in the relationship.

She kept asking: why is this data always three days old? Why does the most important signal, whether a key contact is actually engaged, have to be manually entered by someone who may or may not remember to do it?

The answer she kept getting was: that's just how CRMs work. But the infrastructure to do it differently existed. The problem wasn't technical capability. It was that nobody had built relationship signal tracking as a first-class data problem.

When we started comparing notes

When Marta and I started talking about this, the overlap was immediate. I had the domain problem: reps couldn't see what was happening in account relationships. She had the technical framing: relationship signals are a real-time data problem, not a logging problem.

We also agreed on what we didn't want to build. We weren't interested in another layer of manual data entry, or a fancier dashboard for reviewing what already happened. That approach has been tried many times. The existing revenue intelligence platforms are powerful, but they're built for mature RevOps teams with dedicated admins and weeks to configure.

The teams we were thinking about were smaller. Two to fifteen reps. Working complex deals without the support structure to run Gong or Clari at full capacity. They needed something that worked on day one and didn't require a full-time admin to keep current.

What we decided to build

We started from three constraints: it had to track relationship signals automatically, not through manual rep logging; it had to be interpretable as a next action, not just a report to read; and it had to be accurate enough that reps would actually trust the nudges it sent.

The relationship graph came first, because it was the piece the manual workarounds couldn't scale. Centralyse ingests contact interaction data from CRM, email metadata, and calendar activity, and builds a weighted map of who's engaging, at what frequency, and whether that engagement is trending up or down. Champions are visible. Contacts who've gone quiet are flagged. Relationships that were never there show up as gaps.

The nudge system came second. The graph is useful for understanding an account. The nudge is what makes the graph actionable. One specific thing for the rep to do today, based on what the signals actually show.

Where we are now

Centralyse was founded in 2024. We raised a small angel round in late 2025 from people who understand B2B sales software. We are currently working with a cohort of design partners, sales teams who are using the product in active deals and helping us understand where the signal quality matters most and where we still have work to do.

We bootstrapped the early build ourselves, which meant making decisions carefully about what to focus on. We're not trying to replace a CRM. We're not trying to do everything revenue intelligence platforms do. We are trying to do one thing well: show a rep what's actually happening in their accounts and tell them what to do about it before it's too late.

The problem that motivated Centralyse is real, and it's still mostly unsolved for teams that don't have enterprise tooling budgets. We built this because we kept running into it, and because the pieces to solve it exist now in a way they didn't a few years ago.

Join our design partner cohort

We are accepting a small number of B2B sales teams into our early access program. Work directly with us to shape the product while using it on your real deals.

Request Early Access About the team