One Core, Two Skins: Building Two Audiences From the Same Engine

Serving two meaningfully different audiences, say, a technical operator who wants full detail and a business user who wants a simplified, high-level view, from one shared underlying engine is an appealing architecture on paper. Real usage tends to reveal that the right seam between "shared core" and "audience-specific skin" isn't visible until you've actually built against a first attempt and felt where it breaks. A production visualization engine went through three distinct implementations trying to find that seam: a first version was replaced with a dedicated graph implementation built specifically for one audience's needs. That version didn't generalize well to the second audience, so the team rebuilt on the original pre-overhaul engine instead, effectively backing out of the specialized approach. The final version rebuilt the shared graph again as a genuinely audience-agnostic core, with the two skins built as true presentation layers on top rather than forks of the underlying logic. The practical lesson for anyone building a similar dual-audience system: don't design the shared core in the abstract before either skin exists. Build the first skin fully, let its real requirements surface, then build the second skin against the same core and treat the friction points, wherever the first skin's assumptions don't hold for the second audience, as your actual design spec for where the core/skin boundary needs to move. Expect that boundary to move more than once.