Multi-Sided Systems Blur Faster
The issue wasn’t that the user was vague. It was that there wasn’t just one.
On the surface, it looked simple.
Take a sitemap. Extract content. Turn it into signals.
That part made sense.
But the build exposed something else. This wasn't a single-user system. It had two sides:
- The developer using the tool
- The visitor experiencing what the tool enables
Not competing. Not conflicting. But different vantage points into the same outcome.
The system sits between them
The developer interacts with: CLI, config, processing rules.
The visitor experiences: relevance, structure, meaning.
They never meet, but the system connects them.
Where it starts to blur
If you only think about one side, the other becomes implicit.
- Focus on the developer: the tool becomes flexible, but the output becomes generic
- Focus on the visitor: the output becomes clearer, but the tool becomes rigid
If neither side is explicitly named: decisions get deferred, output becomes generally useful, and the system works but doesn't clearly serve either side.
What was actually missing
It wasn't just: "Who is the user?"
It was: "Which side of the system is this decision for?"
Because every part of the build belongs somewhere:
- CLI and extensibility: developer side
- Output and structure: visitor side
- Signal processing: sits between both
Without that separation, the system expands sideways.
Small repos, clear decisions
An approach: each problem gets its own repo. Small, focused, one job.
The sitemap-signal-guide was what prompted this post.
Key takeaway
When a system is multi-sided, naming the user is not enough. You need to name the sides and know which one you are shaping at any moment. Otherwise the system won't break - it will just blur.
If you've built something where the value only exists because two sides meet, that's worth bringing to a weekly workshop.