I built a working product and people still don't understand what it does.
I spent months building a product before realizing something important:
People didn't understand what it was.
The product is called Debsync.
Technically, it works:
• Users record obligations
• Participants confirm them
• The system finds circular settlement opportunities
• Everyone approves
• A settlement certificate is generated
The problem?
When I showed it to people, the first question wasn't:
"How does it work?"
It was:
"What is this?"
I realized I had spent too much time explaining the technology and not enough time explaining the problem.
Now I'm considering repositioning it away from "debt tracking" and toward helping independent professionals and small businesses manage service-based obligations, agreements, and mutual settlements.
Examples:
• An electrician helps a landscaper
• A landscaper helps a hair stylist
• A hair stylist helps the electrician
People often keep these arrangements informal.
Debsync tries to help participants record them, confirm them, and close the loop together.
No money moves through the platform.
I'm curious:
When you read this, what do you think Debsync actually does?
And more importantly:
Who do you think would actually use it?
I'd love brutally honest feedback.
— Meiram
The understanding problem for infrastructure tools (APIs, webhooks, data feeds) is almost structural - the person who would benefit most often isn't the person who evaluates it.
For goffer.ai (government data webhooks), "legislative monitoring as a webhook" made sense to developers immediately. Compliance officers heard it and thought "sounds technical, not for me." The framing that worked: describe the output state, not the mechanism. "Get a Slack message when a bill affecting your industry passes committee" converts better than "subscribe to legislative events via webhook."
If you're seeing blank stares, it usually means you're describing the plumbing. Try describing the kitchen.
Thank you. This is one of the most useful observations I've read in a long time.
The distinction between explaining the plumbing and explaining the kitchen is incredibly valuable. It helped me realize that we've been spending too much time describing how the system works and not enough time describing what people actually gain from it.
For Debsync, the challenge is exactly that: the underlying mechanics are network analysis, obligation graphs, and settlement cycles, but the real value is much simpler — helping people see opportunities they cannot currently see and helping participants reach voluntary settlements through mutual consent.
Your comment gave us a much clearer way to communicate that value.
Thank you for taking the time to share this insight.
The next test is saying the kitchen version out loud to someone who hasn't seen the product before. If they ask a follow-up question instead of nodding politely, the framing is working. If they say "oh interesting" and change the subject, try again. The blank stare is actually useful data - it tells you exactly where the frame breaks.
Honestly this whole thread taught me more than I could add, bookmarking it.
The thing I can offer is just my own mistake: I kept trying to invent better words for my product myself, when what finally helped was using the exact words a new person used the first time they saw it. Showing it for ten seconds and asking them to explain it back was humbling but useful.
Someone recommended April Dunford's Obviously Awesome to me for this, still on my list. Rooting for you, the circular-favor idea is lovely.
Good move. Leading with that 'relationships get weird' moment is much stickier than the mechanics. Once you have a line that makes people nod before you've explained anything, you know you're close. Would be curious to hear how the reframe lands when you test it.
This is a great point.
I’m realizing the same thing now — I’ve been trying to invent the perfect wording myself, but the clearest language is probably coming from how people describe it after seeing the examples.
The 10-second test is a good idea. I’ll try showing the page to a few people and just ask them to explain it back in their own words.
Also appreciate the book recommendation — Obviously Awesome keeps coming up, so I probably need to read it.
Thanks for the encouragement.
The positioning problem you have isn't rare. I hit the same wall with Genie 007. I was explaining the technology (voice AI, automated follow-up) when people needed to hear the outcome first. The fix I found was leading with the problem the person gets blamed for when it doesn't happen. For a settlement tool, that's probably: someone owes someone something, nobody remembers, relationships get weird.
That makes a lot of sense.
I think you’re right — I’ve been explaining the system before making the uncomfortable moment clear.
“Someone owes someone something, nobody remembers, relationships get weird” is probably much closer to the real problem than the technical settlement language.
I need to lead with that feeling first, then explain how Debsync helps after.
Appreciate you sharing your experience with Genie 007 too — that’s helpful.
Honest first read: it sounds like "a way for people who trade favors/services to keep score and settle up fairly without money or awkwardness." The "circular settlement" framing is what loses people, that's the mechanism, not the benefit. Your electrician/landscaper/stylist example is 10x clearer than the product description; lead with that, not the tech. Who'd use it: tight-knit professional circles who already barter informally and hate the "who owes who" tension. The repositioning instinct is right, sell the closed loop and the fairness, not the settlement engine.
That’s a very clear way to put it — thank you.
I think you’re right: “circular settlement” is the mechanism, not the benefit. The benefit is fairness without the awkward “who owes who” tension.
The electrician / landscaper / stylist example seems to make the idea much easier to understand than the technical product description.
I’ll probably lean more into the closed-loop and fairness angle, especially for tight-knit professional circles that already trade favors or services informally.
Really appreciate this.
When I read this, I don’t think “debt tracking” is the strongest framing.
It sounds more like a trust layer for informal value exchanges between small businesses or independent professionals — especially when people already know each other, but the agreement is too messy to keep only in memory or chat.
The users I’d imagine first are not random consumers, but small local service providers who often trade favors, referrals, work, or delayed obligations: freelancers, tradespeople, consultants, maybe small agencies.
The hard part might be explaining the pain in one sentence. Something like: “When small businesses help each other without immediate payment, Debsync helps everyone remember, confirm, and close the loop fairly.”
That feels clearer to me than “debt tracking.”
This is really useful, Dan.
“Trust layer for informal value exchanges” feels much closer to what I’m trying to explain than “debt tracking.”
I also like the way you narrowed the first users: not random consumers, but small local service providers who already know each other and often trade work, referrals, favors, or delayed obligations.
That one-sentence version is helpful too. I think I need to lead with that kind of situation first, then explain the settlement part after.
Appreciate the clear read.
My first impression honestly wasn't debt tracking.
It felt more like a way to formalize informal exchanges between people who already trust each other.
Reading your examples helped a lot more than reading the feature list.
The interesting part to me wasn't the circular settlement logic. It was the fact that everyone involved can agree on a shared record of what happened.
That was the point where I started understanding the problem.
This makes a lot of sense.
I think you put your finger on the part I wasn’t explaining well. The value isn’t really “debt tracking” or the settlement logic by itself. It starts with everyone agreeing on the same version of what happened.
The examples seem to do a much better job than my feature list, so I’ll probably rewrite the page around that idea: people already trust each other, but they still need a simple shared record before things get messy.
Really appreciate this — very useful feedback.
I think the confusion is happening before the feature explanation.
Right now Debsync feels like a system searching for a problem instead of a painful moment searching for a solution.
The hard part may not be “what does it do?” The harder part is what specific situation makes someone urgently care enough to record, confirm, and settle obligations in the first place.
I’d be careful with broad repositioning too quickly, because the wrong first buyer can make a useful workflow feel unnecessary.
That’s a very fair point.
I think you’re right — I probably started by explaining the mechanism before making the painful moment clear.
The real use case is not “people need cycle detection.” It’s more like: people help each other, cover costs, split things, or promise to return something, and later small obligations become awkward, forgotten, or unfair.
Debsync should probably start from that moment first: record and confirm obligations clearly, then show when they can be settled through the network.
Appreciate the push — this is exactly the kind of feedback I was looking for.
I think that's the right distinction.
The reason I'd still be cautious is that several painful moments can fit that story, but they don't necessarily produce the same buyer or the same willingness to adopt a new workflow.
The useful part is making the actual call on which moment Debsync should own first.
I wouldn't make that decision casually in a thread because it ends up shaping much more than the messaging.
If you'd like the tighter version, drop your email and I'll put it together properly.
[email protected].
Sent you a note by email. I think the first-buyer decision matters more than the workflow explanation right now.