Why We Rebuilt Our WebGL Agent Visualization Three Times

"One engine, two skins" is a clean idea on a whiteboard. Building the actual shared core that serves two genuinely different audiences well, in this case a technical operator view and a simplified business-facing view, took three separate rebuild passes of the same visualization engine. The first version was replaced with a dedicated strand-graph implementation. That one didn't hold up under real use, so the team rebuilt on the original pre-overhaul engine instead. The final version rebuilt the center graph again as a genuinely shared core engine. The lesson isn't "don't try to share a core between audiences." It's that the right abstraction boundary usually isn't visible until you've built at least one full skin against a first attempt and felt exactly where it strains. If you're building something similar, budget for a rebuild of the shared layer once your second audience's real requirements are known, not guessed at during initial design. WebGL and canvas-heavy UIs are especially prone to this because performance constraints (frame rate, memory, draw calls) interact with the abstraction in ways that only show up under load.