I built a company to fix something I could not unsee, and then realized I was fixing it for the wrong customer. Here's the story, because the pivot taught me more than the original idea did.
It started with something small. A crypto project gets something wrong, so you go looking for help. Its website points you to a Discord. You open the Discord, and the pinned message warns you about impersonators and says staff will never DM you first. Then someone DMs you. They are in that same Discord, because the official support channel is also where the scammers wait. The official help path opens by telling you the official help path is dangerous.
I could not unsee that. So I built a company to fix it.
More of normal life is moving on-chain every year. Not just trading. Savings first, and then, slowly, the things that sit behind savings: retirement, equities, the boring money. That shift brings a steady wave of people who are new to all of this. They are not here for the casino. They are people who happen to have real value on a blockchain now, and who will, eventually, need help with it.
Here is what help looks like for them today. The app or protocol sends you to its Discord or Telegram. The channel greets you with a scam warning about itself: do not trust DMs, staff will never message you first, verify every link. And the people that warning is about are right there in the channel, watching for someone confused enough to talk to. The support surface and the predator's hunting ground are the same room. Crypto-native users have fully normalized this. They learned the survival rules so long ago they forgot they ever had to learn them. A newcomer has not. The moment you say the loop out loud to someone outside crypto, it sounds insane, because it is.
Then I watched large lending protocols start pulling out of Discord and Telegram, in part over exactly this. The support surface had become a liability they did not want to own.
So I built TxDesk. The first version was B2B: support infrastructure a protocol could run so its users got real answers instead of a scam-infested chat room. Underneath, the product did something specific, and it is the same thing it does today. It reads live on-chain data and explains it in plain language. It decodes a transaction, checks an approval, looks at what a contract actually is, and answers from live on-chain data. It is read-only with respect to your funds. It never asks for or holds a private key. The bet was that protocols would adopt this as their support layer.
Then I paid attention to what actually happens during an incident. When a protocol is being exploited, its attention goes exactly where it should: pause the contracts, trace the funds, pull in security people, coordinate, get a statement out. That is the correct priority for the protocol in that moment. The consequence is structural, not a moral failing. The thousands of individual users flooding in with "am I affected, was my wallet exposed, where are my funds, am I safe" are not, and cannot be, the priority in that window. The buyer I was selling to did not want to own that layer the way I had assumed. At the exact moment it mattered most, answering the individual user was nobody's job.
That reframed the whole thing for me. The people who have the questions, and the worry, and the money on the line, are the users. Not the protocols. The demand had been downstream the entire time. I had built the right tool and pointed it one customer too far upstream.
So I pointed TxDesk directly at the people who actually ask "am I safe." Same product underneath. Same thesis: people are coming on-chain and they need real answers, not a chat room with a scam warning pinned to the top. Different customer. The version I am building now lets the user ask the chain directly, in plain language, and get an answer grounded in what is actually on it.
I am not going to quietly pretend it was always this. It was not. I built it for one customer, learned the demand lived with another, and moved. The consumer version is what I am building now.
Still early on the consumer version. If you've made a B2B-to-B2C pivot, especially the awkward part of telling an existing audience the thing changed, I'd want to hear how you handled it.
Full write-up here: https://dev.to/txdesk/i-built-txdesk-for-the-wrong-customer-here-is-what-that-taught-me-jib
the tell was in the sentence: "the buyer I was selling to did not want to own that layer." that is the B2B-to-B2C signal every time. when your business customer keeps deprioritizing the feature you sell them, the value lives with the end user and you are adding a step that makes things worse, not better.
quick test for anyone sitting on the same question: remove the B2B buyer from the chain mentally. does the product get simpler or harder to deliver? if simpler, you were always B2C. the B2B framing was a distribution hypothesis, not a product one.
One thing I've noticed is that founders often assume the problem is positioning when it's actually visibility.
The right signals are usually there much earlier than we realize.
A customer keeps asking a certain question.
A specific type of buyer keeps engaging.
The same objection keeps appearing.
Looking back, those patterns often seem obvious. In the moment they're buried under everything else happening in the business.
Curious what the first clue was that made you realize you had the wrong audience?
joshnemecs question (easier to reach vs more willing to pay) is the right one to answer here, the framing of 'who was the demand actually living with' is sharper than B2B-vs-B2C as a heuristic. the part that maps for anyone reading this and isnt in crypto: there are products where the b2b buyer has the budget but no urgency, and the end-user has no budget but immediate panic. exploit moments make that visible because they collapse the decision window from months to minutes. if your demand spikes during incidents your customer is downstream, full stop.
"The demand had been downstream the entire time" is the line I'll be stealing. I'm building for both the individual and the org, and I made the same bet in the opposite order on purpose — lead with the individual, defer the B2B layer — mostly because I didn't trust myself not to over-build for the upstream buyer first.
Can't speak to your hard part yet (I'm pre-launch, so there's no existing audience to re-aim) — but "which customer was the demand actually living with" is a sharper question than B2B-vs-B2C. Curious: were the downstream users easier to reach, or just more willing to pay?
This is a very real shift a lot of founders underestimate until they’re inside it.
The “who is this actually for” answer often only becomes visible after the first system is already working.