Where Did Your Customer Feedback Actually Go?

By Junaid Ahmed

---

I clicked the Feedback button inside PodGlue. I typed a test message. I hit Submit.

The issue landed in the wrong team.

That sentence is the whole post if you want the short version. The longer version is more useful, because the fix is not what I expected.

---

What I thought I was checking

PodGlue has a Feedback button in the top bar. A user types a message, picks "bug" or "idea" or "question" or "other," and it creates an issue in Linear for us to triage. Standard product hygiene. I wrote it months ago, and once the first few real reports came in, I stopped thinking about it.

This week I went to verify something unrelated and ended up pulling on the wrong thread. I wanted to confirm one thing: that the Feedback form was routing to the team that actually triages it.

When I looked at the Linear history, I found something I didn't expect. There were two clusters of feedback issues. One cluster, from January and February, had landed in our old Humblezone Linear team. The team nobody had been actively watching for product reports. All of those tickets were now marked Canceled, which is the polite name for no one acted on this.

The second cluster, from March onward, had landed in the right place. The PodGlue team. Somebody had quietly fixed it in March by changing a setting somewhere.

I went looking for the change in the codebase. There was no change in the codebase.

---

The thing you can't see in the diff

The destination of every feedback submission is a single value, LINEAR_TEAM_ID, stored as a Supabase secret. It is not in our git history. It has no diff. It has no review. Nobody had to approve setting it. Nobody had to approve changing it. When I asked our infrastructure, "where does the Feedback button go right now?" the honest answer was somewhere, depending on what was last typed into a dashboard.

The right fix in March was to update that secret. The accidental thing in January was someone, somewhere, having pointed it at the wrong team.

Neither event left a trace.

I also found that the deployed edge function had been hand-edited at some point, different label names, an extra try/catch, that never made it back into the repo. So the repo wasn't the source of truth either. It was a story we'd been telling ourselves about what was deployed.

---

What "drift" actually feels like

When I worked in video production, the most expensive mistake on a shoot was almost never something dramatic. It was a knob.

Someone bumps the gain on the second mic between takes. The level meter still looks fine. The talent sounds fine in the headphones. You shoot for two hours. You go home. Three days later in post, you notice one speaker is slightly hot in every clip. You can't fix it without going back to the raw audio and crawling through every cut. The person who bumped the knob doesn't remember bumping it. The mixer doesn't remember being bumped. There is no log.

That is what config drift feels like as a founder.

The deployed Feedback function had drifted from the repo. The secret had drifted from the team it was supposed to point at. Both things looked fine on the surface for weeks at a time. Both showed up only when somebody, me, this week, sat down and asked wait, where is this actually going right now?

---

The fix is structural

I confirmed the live destination by submitting a test feedback and watching where the Linear issue landed. (It landed in the right team this time. I canceled the test issue.) I synced the repo back up with the deployed function, so the codebase reflects reality again, and CI will redeploy from the repo on the next merge.

But the real lesson is not check your secrets every quarter.

The real lesson is that anything you only-configure-once needs to live somewhere a human will see it again. A secret in a dashboard is not that. A hand-edited deployed function is not that. They are tunable knobs with no log next to them. They will drift, and you will not hear the drift, and the cost of the drift compounds in the people who quietly stopped getting heard.

If a setting determines who hears your customers, it belongs in code, in a pull request, in a diff that another set of eyes will read.

---

Why this matters more for a feedback channel than for almost anything else

When a billing webhook silently misroutes, you find out fast. Money flows wrong, dashboards turn red, someone calls.

When a feedback channel silently misroutes, you find out slowly. There's no alert for "the people who took the time to tell you what's broken are talking into a closet." The signal is just an absence. Fewer reports than you'd expect. A growing sense that the product is quieter than it should be. By the time it's obvious, six weeks of patient, well-meaning customer notes have been Canceled by a stranger who doesn't even know what they're looking at.

The whole reason a feedback button exists is to close the loop between the people using your product and the people building it. A misrouted feedback button doesn't just lose data. It quietly breaks the promise the button was making.

---

I clicked Submit. The issue landed in the wrong team. Most of what I learned was in the part where I went looking for who, exactly, had decided that, and found out nobody had. The system had decided. The system was a secret nobody had reason to look at.

The Feedback button is back where it should be. The thing I'm going to remember is the six weeks that it wasn't, and the fact that nobody noticed.

---

PodGlue is, among other things, a tool for not losing track of the people who took the time to talk to you. The same instinct that built the Feedback button is the instinct that built the rest of the product. You can't tend a relationship, with a guest, with a customer, if you can't tell which ones you've heard from and which ones you've quietly ignored. It is in beta now.

Junaid Ahmed is the host of Hacks & Hobbies and the founder of PodGlue.