CredoGrid moves warm introductions through dual-party escrow — credits lock on request, release on confirmed connection, and dispute resolution defaults to the requester. The result is a marketplace where reputation, not promises, settles the trade.
Warm introductions are the highest-converting B2B channel and the lowest-trust market. CredoGrid is a two-sided marketplace where requesters spend credits to ask for an intro and connectors earn credits when the requester confirms the intro happened. Credits sit in dual-party escrow, credibility scores track reliability over time, and disputes resolve through a documented lockbox-release rule. The whole thing runs on a Hono API inside a Next.js monorepo, with Redux Toolkit on the client and Drizzle + Postgres at the data layer.
Every founder has the same shortlist of people they wish they knew. Every operator has the same overflowing inbox of people asking to be introduced to those founders. The market exists. The market does not clear. Warm intros are the most valuable thing one professional can give another — and the most reliably dropped, ghosted, half-honored, or quietly used as social leverage and never delivered.
Existing tools try to solve this with karma, leaderboards, or paid intro services. None of them work because none of them are actually transactional. Karma is reputation without consequence. Leaderboards reward volume, not quality. Paid intro services hide both parties from each other, which kills the warmth that made the intro valuable in the first place.
“Warm intros are the highest-converting B2B channel and the lowest-trust market. We built the missing settlement layer.”
The brief we set ourselves was specific. Build a marketplace where (a) the requester can see the connector's reliability score before spending a credit, (b) the connector can see the request fully before accepting, (c) the credit is locked in escrow until *both* parties confirm the intro actually landed, and (d) when there's a dispute, the requester's assessment wins by default — because they're the one bearing the cost of an unhonored ask. That last clause is the whole product.
Credibility is the currency. Credits are the unit of account, but the actual valuable asset is the score above the credit balance. People don't optimize CredoGrid for credits. They optimize it for not losing their score.
Dual-party handshake escrow. Credits lock on request, release only on both confirmations.
CredoGrid is one of Synara's own products. We were the customer first — every Synara engagement starts with at least one warm intro, and the failure modes of that channel were directly costing us business. The product is what we'd been quietly building in Notion and Linear tickets for years before deciding it deserved its own codebase.
Marketplace mechanics live or die on the data model. Escrow + scoring + disputes need to be primitives, not afterthoughts — and getting them wrong on day one means re-architecting the table layout while real money is in play. We built CredoGrid as if it had to handle real escrow from day one, even when the credits were still functional placeholders. The schema we shipped in week three is the schema we still run.
A credit transaction locks on intro request. It releases to the connector only when *both* the requester and connector confirm the intro landed. Either party can mark the connection failed; an unanswered confirmation auto-refunds after a configured window.
Each user carries a credibility profile, not a credit score. Response time, completion rate, dispute history, average request quality — all separately visible. Other users see *how* you're reliable, not just *that* you are.
When parties disagree on whether the intro landed, the requester's assessment defaults to wins-by-default and 75% of the escrow transfers. The rule is published in the product, not buried in TOS. Predictability is the trust mechanism.
A connector can't appear in search until they've fielded at least one request — successful or not. Empty profiles never accumulate inbound. Reputation must be earned before visibility.
Requester view: pending requests, escrow balance, credibility-by-connector. Connector view: incoming requests filtered by relevance, response queue, earnings, score trajectory. Same product, two completely different operational surfaces.
Public leaderboards are scoped — top connectors in B2B sales, top connectors in early-stage VC, top connectors in supply chain. Volume alone doesn't rank — completion rate and average score weight more.
Reputation has shape, not just a number. Other users see *how* you're reliable.
MethodologyArchitecture metrics are properties of the deployed codebase. Market mechanics are documented in the user-facing rules surface — predictability is part of the product, not a marketing claim.
The first marketplace I've used where I trust the rules. I know what happens if the intro lands, I know what happens if it doesn't, and I know what happens if we disagree. That's the entire product.
Vertical-specific leaderboards (vertical SaaS, supply chain, healthcare). A connector recommendation engine for requesters with under-formed asks. And a small marketplace of *paid* intro brokers for high-stakes asks where the credit unit needs to escalate.
Most marketplaces ship features. Trust marketplaces ship rules. We can scope an escrow-mediated two-sided product — connection brokerage, services exchange, gig settlement, anything where neither party will move first.