eight months, two dead products, and the thing we spent five of them not building
Eight months ago Saurabh and I started building something called Kloop Signal. Today we launched Kloop, which is a CRM. In between we built two things and deleted both.
The part that doesn't fit in the launch tweet is that for five of those eight months we were avoiding the actual problem. Not because we couldn't see it. Because it was big and we didn't want it to be the only answer. We felt we could take a path to bigger product than building one right away.
Kloop Signal sat on top of your CRM. You connected HubSpot or Salesforce, our agents read what was in there and wrote back what the CRM couldn't tell you on its own: a health score per deal, relationship strength per account, which deals had gone quiet, which ones were advancing without anyone in the room who could actually sign.
It worked. The scoring was good, demos went well, people nodded in the right places.
It just didn't matter enough.
Our design partners were four and six person companies, and Signal asked them to open a second tab every day, right next to the CRM they were already not updating. So we'd built something that needed the sustained daily attention of the people with the least attention to give, and every call ended the same polite way.
yes, this is useful. no, nobody is opening it on Tuesday.
The other reason is the one I'd actually tell another founder. Read a description of Kloop Signal and ask what it is. Deal scoring, summarising, surfacing risk, drafting the next step. That's a feature, and it's a feature the CRM underneath is already growing, because every CRM is going AI-native right now. We were signing up to spend two years defending a position HubSpot would eventually occupy for free.
If you're building a layer, the question isn't whether your layer is better today. It's whether the thing underneath is learning to do what you do.
HubSpot was.
If the intelligence has to live inside the record rather than on top of it, then it isn't a layer at all, it's a harness. It reads the raw material, writes the fields, works out what changed, and asks when it genuinely can't tell. You can't bolt that on from outside, because from outside you only ever see what somebody already typed in.
A CRM records what happened. What decides a deal is usually what didn't: procurement never got into the room, the champion stopped replying somewhere in March, the person who signs never saw the product. None of that has a field, because none of it is an event. You only see an absence if you are holding the raw material and know what should have been in it.
Which is how we ended up building a CRM.
I really did not want that to be the answer. The category is thirty years old and full of companies worth billions, and the plan was always to start narrow, one vertical or one ICP, and widen from there. Rebuilding the system of record is not how that plan starts.
So we spent five months building around it instead.
Founder-led sales, and not off a market map. Saurabh has been that sales person, at Freshworks and at SuperOps, he's done the Sunday night CRM catch-up, and between us we could get to fifty more and actually talk to them.
That's the whole selection criteria. We picked the customer we understood and could reach.
The pattern that showed up is the most useful thing in this post whether or not you ever look at Kloop. While you're the only one selling, an empty CRM costs you nothing, because you are the CRM. Every deal, every objection, every reason someone went quiet in March is in your head and your inbox and available to you all the time, so updating a database returns you nothing and priority #99 is the correct priority.
Then your first AE starts.
Now the context has to leave your head, and there's nothing holding it, so it leaves through you, in meetings, over Slack, in the same four explanations again and again. They ramp for weeks. Deals that should close don't, because they're missing why the customer cared and which objection was already handled.
the CRM never hurts while you're the only one selling. it sends the bill the day you hire.
Every CRM ever built assumes a person whose job is to feed it. That isn't a criticism, it's the design. Fields, stages, required properties, activity logs, all of it assumes a rep who logs and a manager who reads, and the model works fine when data entry is somebody's actual job.
The founder is neither of those people and is never going to become one.
so the fix isn't a nicer form. it's not having a form.
Connect your email, calendar and calls. Kloop reads them and writes the records itself, what changed and why it matters, applying what it's confident about and stopping where it can't tell what you'd have wanted. In the morning there's one brief: what moved, what's at risk, the few things worth doing today. Correct it once and it remembers.
What "reads them" means is the part I'd have been sceptical of. Email and calls are the obvious ones. The sources that changed how the record reads are the others, Slack where the deal actually got decided, PostHog and Mixpanel for whether the account is using the thing they bought, Linear for the blocker they keep asking about.
None of that is data entry you were failing to do, it's data entry nobody was ever going to do. Nobody joins a renewal date to a support thread to an activation curve by hand, it's twenty minutes per account per week and there are seventy accounts.
The brief is the first thing in the morning: what moved overnight, what is at risk, the few things worth doing today. It is also read aloud, so you can take it on the way in rather than at a desk.
Before a meeting it pulls together who you are seeing, what happened last time, what is still open and what is worth asking.
Who you are meeting, what is open, and what to ask.
After the call there is an honest read: what got covered against what you planned, the moments that mattered, and the follow-ups already drafted.
It answers questions about your own pipeline in plain English, and shows its working rather than asking you to trust a number.
Ask in plain English and get an interface back, with the memories it recalled and the tool it called shown above it.
It writes continuously and stops where a change is expensive to undo. Every write cites what it read, with a confidence score attached.
Approvals and rejections both feed back. The reason you type when you reject something becomes a boundary, a confirmation becomes a fact, and both get loaded into the next run. The practical effect is that the longer you use it the less it asks you.
What it has learned working alongside you. Open any one to review it, or forget it.
And because it's reading your inbox, what a teammate sees is a decision rather than a default.
Every level renders the exact thing a teammate would see, so you are not guessing.
Users are unlimited. We charge for the work Kloop does instead of a person.
An Assist is one piece of that work. Nothing you type is one. An email filed is one Assist, a call graded is twelve. The bill grows with the work, not with the headcount.
Meetings, briefs, records and the ones you asked for, counted and costed as they happen.
This is the harness part, and it is mostly boring on purpose.
Every agent runs as the user. Not a service account with a big key, the actual person inside their org, and the database enforces that with row level security rather than the app remembering to check.
The bit I'd defend hardest is the evidence gate. An agent can't write a field unless it cites something it read during that same run. Weak evidence or none and the write doesn't fail quietly, it goes to a judge council, which approves it, holds it for you, or rejects it (and a rejection becomes a memory, so it stops trying that particular thing on you).
The ledger is written as it happens, so if a run dies halfway you still have every step it took and what it read at each one.
About forty tools in five families, five agents, one database. Most of it isn't clever, it's the boring scaffolding that makes an agent safe enough to leave running overnight on somebody's real pipeline.
if it can't tell you where it got something, it doesn't get to write it.
48 views
@saurabh_p and I have spent the last eight months building Kloop, and today we're launching something quite different from what I set out to build. The first version was a layer on top of your CRM. A stack of agents that took the manual grunt work off revenue teams. It worked.