The Client Who Found Us Himself
A buyer paid for our tool through a middleman. When it broke, the middleman went silent — and the buyer tracked the developers down directly. What happened next changed how we do business.
Toản and I build a YouTube automation tool — call it "the manager." For months it sold through a middleman, a guy who handled the sales, the pricing, and the relationship with buyers. It seemed to work. The middleman would find someone who wanted the tool, we'd build and ship, he'd handle support.
Then the tool broke for one of those buyers — and we found out, from the buyer, that the middleman had been keeping us apart the whole time.
The setup
A client — let's call him H — bought the tool through the middleman and ran his channel network on it. It worked for a while. Then it started misbehaving: a voice feature read gibberish, some image edits failed. H reported the bugs to the middleman and waited. Days passed. He messaged, called, waited some more. Nothing.
So H went looking for the actual developers. He found Quang's email from months back, then the Facebook profile, and reached out directly. That's how we learned our tool was broken at a paying customer's site — not from the middleman, but from the customer, four or five days after the fact.
What we found out in the first call
The call with H was 80 minutes of business, then a private debrief between me and Toản that was, frankly, the more interesting half.
- H had paid for the tool. The middleman had reported a different, lower price back to us, and the difference — a slice of what H actually paid — was unaccounted for. We'd never seen the real number because we'd never talked to the buyer.
- H had been told "buy once, no more feature updates," while the middleman had separately promised him updates. Two different stories to two different audiences.
- H had co-designed the tool's features with the middleman a year earlier, with screenshots to prove it. He felt abandoned: the tool took shape and he was never put in the support group, never updated, never told about changes.
- From our side, we were the "internal dev team" for the middleman, building to his specs. We'd never seen H's mockups. We were building for a client we didn't know existed.
Every number in this story was a roundabout way of saying the same thing: the middleman had no incentive for us to meet. Pricing opacity, unreturned bug reports, no support channel — all of it was a symptom of a broker who wanted to stay in the middle.
What we did
We didn't blow up the relationship. We worked around it:
- A direct line. We made a Zalo group with H and started fixing the reported bugs for free. Small, concrete, visible progress.
- Feature-flagged rollout. Before shipping the next version to H's instance, we deployed with new features disabled behind flags. He got the latest code, but the shiny new stuff stayed off until we'd deliberately turned it on — so a half-baked feature couldn't break his operation.
- Free fixes, paid features. All current bugs: free, no questions. Anything new and substantial — lip-sync, channel-suspension alerts — becomes a separate paid arrangement. That's the pricing model that survived this incident, and I think it's the right one.
- A front person. We put someone else forward as the point of contact for H, so the middleman's feelings didn't become our problem. The same three people did the actual work; there just wasn't a need to tell the broker everything.
And we quietly removed the middleman's admin access from H's instance before deploying. That last one was a decision made in the private debrief, and I remember Toản's reasoning being blunt: just remove him.
What I'd tell my past self
- Meet your customers before you need them. We spent months building for a broker's interpretation of a customer. The customer had opinions, mockups, and years of context we never saw. Distribution without contact is how you end up building the wrong thing for the right person.
- Pricing opacity is a feature for someone. When one number is told to the buyer and another to the builder, the gap doesn't evaporate — it goes somewhere. Whoever controls both stories controls that gap.
- Support is the real relationship. The middleman lost the account the day he stopped answering bug reports. Everything H did next — finding us, testing, paying for features — was downstream of "my bug report got ignored for five days."
- The direct connection is worth the awkwardness. Keeping a middleman happy by keeping his clients at arm's length is a bad trade. We took the uncomfortable path — talking to the actual human who runs the actual channels — and it's the best business decision we've made this year.
We didn't fire the middleman. We didn't have to. By the end of that week, H had our number, we had his, and the middleman's role had quietly become optional. The tool works, the client's channels are back up, and the lesson that stuck with me isn't about the money — it's that the person whose name isn't on the invoice is the one who actually owns the relationship.