We Build Things to Understand Them

There is a difference between knowing how something works and knowing what it does when it breaks.

Most agencies know how things work. They read the documentation, follow the releases, attend the conference, form a point of view. That process produces commentary. It doesn't produce the knowledge you get from being inside the problem: from having made the wrong decision, found the gap in the spec, shipped the implementation, and debugged what the documentation didn't predict.

WM builds things to understand them. Not as a product strategy. As an epistemological position. Every WM-built tool started as a genuine need: something we required in order to do the work we were doing, turned into a real implementation that had to survive contact with production. That's different from having read about it.

Why advising without building is a liability

AI is moving faster than commentary can track. The gap between what a technology is supposed to do and what it actually does in a real implementation is where most projects fail. Agencies that stay current by reading about AI are always one step behind that gap. They can tell you what MCP is designed to do. They can't tell you where the official SDK stops being useful and the real work begins.

WM can, because we've been there. That's not a credential. It's a consequence of a decision to build rather than observe.

What we've built, and why each one started as a need

[create-mcp-server](/case-studies/create-mcp-server/). MCP (Model Context Protocol) is the standard that lets AI systems connect to external tools and data sources. The official SDK gets you to hello world in a tutorial. It doesn't get you to a typed, tested, production-ready server with the right structure for a real deployment. That gap was real and we needed to close it. We built an open-source scaffold (one command, under 60 seconds, MIT licensed) because we needed it ourselves. Published it because the search space was empty.

[AudienceOS](/case-studies/audienceos/). We wanted marketing personas with genuine emotional and behavioural depth: the kind of output that's actually useful in a brief, not a demographic summary with adjectives. No existing tool produced that. We built AudienceOS, a persona generator powered by the OpenAI API with prompt engineering designed to surface psychological specificity. Now we use it in client work.

[AIO Validator](https://aio.workingmodel.co/). AI search engines (ChatGPT, Perplexity, Gemini) are increasingly the first place people look for answers. Whether your content surfaces in those answers is a measurable property of how it's written and structured. Before we built the AIO Validator, no tool measured it. We built one because we needed to know where our clients stood before we could advise them on where to go.

[npm Simple Name Series](/case-studies/npm-simple-name-series/). Five CLI diagnostics for Node.js developers, named after the exact phrases developers type when something breaks: why-is-this-slow, who-ate-my-ram, why-wont-this-install, why-is-this-failing-in-prod, what-is-this-package-actually-doing. Zero config, one command each. Published because the search space was empty and the tools were needed.

The pattern: every build started with a real need in our own work. None of them started as a product strategy or a credibility exercise.

What building teaches that reading doesn't

Specific things WM knows from building these tools, not from reading about them:

The gap between "this should work" and "this works in production" is where the real knowledge lives. MCP's scaffolding problem isn't visible until you've tried to take a tutorial implementation into a production environment. The AIO ranking factors that matter most aren't the ones most written about. The memory leak patterns that actually occur in Node.js production environments are different from the ones that appear in documentation examples. You learn these things by being inside them.

Tools fail in ways documentation doesn't predict. The failures are the curriculum.

Building forces decisions that advising avoids. What's the actual data model? What happens at edge cases? What does the error state look like? What do you do when the API changes? Advising on technology is a fundamentally different activity from implementing it. The decisions that matter most are the ones you only encounter by implementing.

What this means for clients

When WM recommends a technology, it's because WM has used it, found its limits, and worked through them. When WM says something is ready for production, it's because WM has shipped it to production. When WM advises on MCP implementation, or AI persona generation, or content structured for AI citation, the advice comes from having made the decisions those implementations require.

That's the difference between a vendor who reads the spec and one who's debugged the implementation. One of those vendors knows things the other doesn't.