Internally Deployed Users Are the Only Way to Ship Great Software Now

Forward-deployed engineers have been all the rage over the past couple of years. But most software keeps getting shittier. So clearly FDEs aren't the answer to solving enshittification. A different model is needed where the deep frustration with glaringly obvious issues in your software is constantly front and center to someone who can fix them.

Indie hackers and early-stage startups don't have all of the answers, but the pattern for the most successful ones is that they actually use the software they are building. People in organizations who actually want to build better products should figure out what to steal from that model. Let's call them "Internally Deployed Users" (IDUs) for lack of a better name right now. IDUs are the folks within an organization with the explicit role of accomplishing valuable tasks with a product. They create constant, immediate feedback based on their use. Ideally, they enable the team working on the product to have that elusive "taste" which is so hard to define.

IDUs can be part-time but their role must be an explicit responsibility. They aren't doing it just out of the goodness of their own hearts. They are serving in that capacity because someone needs to deeply feel every rough edge and broken promise in a product so they can either fix the issues themselves or yell loudly enough in the direction of the people who can fix them. "Isn't this just dogfooding?" you might rightly ask. Dogfooding is a key part of what an IDU does. But an IDU is a person with explicit responsibility. Dogfooding is too loose of a term for the day in and day out sweating of the details that an IDU does to ensure the product is great.

Here's a recent example that was recently at the top of Hacker News, but it was blindingly obvious to users like me who were frustrated at the time with Claude Code. CC had a ton of quality issues in the spring of 2026. InfoQ reported that Anthropic employees who were supposed to be dogfooding missed all three issues “because internal staff were using different builds.” Anthropic was dogfooding but its employees weren't IDUs because they weren't using the same damn software that customers were using. Fortunately, they recognized the issue and committed to moving more staff onto exact public builds. More companies need to do that. Yes, Internally Deployed Users are dogfooding, but it must be on the same product the users are using.

"Well Matt, this seems obvious and common sense." Yes, that's entirely true, but sometimes you need a new buzzword so Boards start asking their C Suite "What's our plan for IDUs? Do we have enough IDU capacity across the company to improve our products?" Sometimes, the hot new buzzword is enough to drive positive change because it captures the frustration in nice enough packaging that people in charge start to ask their organizations the right questions. In the meantime, serve as an IDU for your own products and give a bump to posts like the one above from Nate and the one below from Dax which provided inspiration to figure out what's missing in today's software product thinking.