Following up on the earlier build diary — here’s what’s actually changed with VyapTrust over the past month, including a real assumption that turned out wrong and what we did about it.
Where we left off: building the narrow-signal MVP model, planning to get it in front of 2-3 lending partners for structured feedback, still uncertain about the right incentive structure for MSMEs to opt into sharing behavioral data.
What we learned from the first lending partner conversations: our assumption that lending partners wanted a single trust output was directionally right, but we underestimated how much they wanted to see the underlying signal breakdown even in an early demo — not just the final score, but which specific behaviors contributed to it. This pushed us to expose more of the scoring logic in the UI earlier than originally planned, which added scope but produced meaningfully more useful partner feedback once implemented.
The incentive-structure problem, partially resolved: we tested two approaches with a small group of MSME owners — pure altruism/product-improvement framing (weak response) versus a concrete, specific benefit framing (“this data helps you build a credit history you don’t currently have access to”) — the concrete-benefit framing performed substantially better in getting genuine opt-in. This isn’t surprising in hindsight, but it’s a real, validated data point rather than an assumption now.
What we got wrong initially: we assumed a broader signal set would be needed relatively soon after the narrow MVP validated. Real lending partner feedback suggests the narrow signal set, done well and explained clearly, is more valuable to them right now than we expected — partners seem to prefer a smaller number of high-confidence signals over a larger, noisier set, at least at this stage of engagement. This is pushing our roadmap to invest more in signal quality and explainability before breadth, a genuine change from the original plan.
What’s next, concretely: refining the signal-breakdown UI based on the specific feedback from initial partner conversations, running a slightly larger pilot with real MSME data (with the validated concrete-benefit opt-in framing), and continuing to hold off on broadening the signal set until the narrow model’s real-world performance data justifies the investment.
Why this update matters beyond VyapTrust specifically: the pattern here — building narrow, getting real stakeholder feedback, and having that feedback push against your own roadmap assumptions — is normal and, if anything, a sign the validation process is working correctly. A build diary that only ever confirms the original plan usually means the founder isn’t actually listening to the feedback closely enough.
Want a direct read on your own situation instead of general advice? Send me a few lines about what you’re building and I’ll tell you what actually matters for your case. Free 30-minute call, no pitch, no obligation. Available for founders in India and Australia. Book a Free Call →
Frequently asked questions
What did VyapTrust learn from initial lending partner feedback?
Partners wanted visibility into the underlying signal breakdown, not just a final trust score — this pushed the team to expose more scoring logic in the UI earlier than originally planned.
What incentive framing worked best for getting MSME owners to opt into data sharing?
A concrete, specific benefit framing (“this helps you build a credit history you don’t currently have”) significantly outperformed a general product-improvement or altruism-based framing.
Did VyapTrust broaden its signal set as originally planned?
Not yet — lending partner feedback suggested a narrower, high-confidence signal set explained clearly was more valuable at this stage than a broader, noisier one, which changed the roadmap to prioritize signal quality and explainability first.
Why publish an update that includes things that changed from the original plan?
Because a build diary that only confirms the original plan usually means the founder isn’t genuinely incorporating stakeholder feedback — real validation should sometimes push back against initial assumptions.