Modern AI Solutions · Pathfinder Suite · 2026
A component framework built to stop ten services from solving the same interaction problems differently. Started as documentation. Shipped as code.
Problem
Pathfinder is a multi-product suite: Tasks, Playbooks, Contacts, Documents, Files, and about a dozen more services sharing one React codebase. We had a component library: buttons, dropdowns, cards, tables. What we did not have was any guidance on how to put them together.
Every service team solved the same interaction problems from scratch. One put Edit in the overflow menu. Another had it inline. A third had no consistent overflow structure at all. Action ordering was arbitrary. Status icons varied. Filter bars were reinvented on every ticket.
The real cost was not inconsistency visible to users. It was the compounding maintenance burden of ten different answers to the same question, each drifting further from the others over time. When our Playbooks list component hit 2,340 lines, it was clear the status quo was not scaling.
The design system had grown the atoms. What was missing was the sentence structure: documented, enforceable patterns for how to combine them, with clear rules for the edge cases.
Users
Pathfinder's end users never saw the framework. The people it served were the designers, developers, and cross-functional contributors building the product. Each group had different friction with the status quo.
Those gaps shaped what the framework had to do: not just document conventions, but enforce them at the component level so the right choice was also the easy one.
New engineers joining the team had no way to understand conventions except by reading the largest, most complex component and making inferences. The framework was meant to make that unnecessary.
Decisions
Decision 1
Once the framework existed, we had to decide how to migrate ten-plus services that were all doing things differently. Fix everything at once, or sequence it?
Why: Option A was too risky. We did not yet know where the framework would break against service-specific data models. Option B was not a migration, it was a hope. By running Tasks first, we caught a real gap before scaling: filter dropdowns needed context-aware options the initial standardized component did not support.
Decision 2
Most design systems stop at documentation. We had to decide whether the framework would be a style guide or a set of importable, opinionated components that enforce consistency at the code level.
Why: With copy-paste, every copy diverges. An accessibility fix to the
action menu would need to be manually applied across ten services. With a centralized
StandardActionMenu, one fix propagates everywhere. The tradeoff was developer
flexibility, but for patterns that needed to be identical, that flexibility was the problem
we were solving.
Decision 3
Every service had its own answer: some put Edit in the overflow menu, some had it inline, some had no consistent rule. Users were finding core actions in different places depending on which part of the product they were in.
Why: The overflow menu's job is to hold actions you do not use every session. When Edit ends up there, you have hidden the most common thing a user wants to do on a given item. The rule we codified: if you would expect to use it multiple times per session, it lives inline. If it is rare or irreversible, it goes in overflow. Destructive actions always anchor the bottom tier with visual separation.
Tradeoffs
The tradeoff we kept running into was consistency against flexibility. The framework's value came from consistency, but the moment it became too rigid, teams would work around it and the inconsistency would return through the back door.
Real moment of pushback
During the Tasks migration, the initial standardized filter component failed. Tasks needed context-aware filter options that changed based on item state, something the generic component did not support.
This was the scenario we had been most worried about. If the framework could not accommodate service-specific needs, teams would reject it and build their own thing, and we would end up with more divergence than we started with.
Adoption and Outcomes
Phase 1 validated the framework on two services before committing to a broader rollout. Phase 2 extended it to Contacts, Documents, and Files, with no significant rework to the core components. Both phases came in without regressions.
VIEW_MODE_KEYS, covering the full migration target through Q4 2026.Developers noticed the difference. Tasks took a fraction of the usual implementation time, and when bugs surface in shared components, the fix goes out once and reaches every service automatically.
Phase 3 is active now. The question I am watching is whether the variant strategy holds as data models get more complex. Agreements and InfoVaults have edge cases the first migrations did not. Those will tell us whether the framework needs a second generation or just new documentation.
The hardest part of this project was not designing the patterns. It was building the framework before the demand was obvious. It paid off because we proved it on a real service before publishing it, and enforced it through code rather than hoping documentation would be enough.
The lesson from the filter dropdown friction is the one I think about most. A design system that cannot flex will be abandoned. The patterns that stick are the ones that make it easier to do the right thing than the wrong thing, not the ones that make the wrong thing impossible.