02 — Building a Connected Product Foundation

How we created a shared administrative and data foundation for a new generation of connected products, beginning with Schedule.

The starting point

Before Core, applications across the portfolio had been built independently. Products used different technologies, patterns, and data structures, with no shared product foundation connecting them.

When the company decided to build Schedule from the ground up, we had an opportunity to avoid creating another standalone application.

Instead, we began with Core: a shared foundation for institutional data, integrations, configuration, and administration that Schedule—and eventually other products—could build on.

01 — Breaking from the legacy model

The goal was to move away from independently built applications and toward a connected product ecosystem.

Core wasn't intended to replace the products around it. It would provide the common structure they needed so each product could focus on the job its users came there to accomplish.

02 — Defining the product boundary

One of the hardest design questions was deciding where Core should end and Schedule should begin.

Administrators still needed the ability to view, manage, and correct scheduling data directly in Core. But if Core became too optimized around scheduling workflows, we would effectively build Schedule twice.

The same underlying data could appear in both products, but the experience changed based on the user's intent. Core supported the administrative control required to keep the ecosystem functioning. Schedule could then turn that data into a focused workflow.

03 — Designing the products together

Core began first, but development eventually overlapped with Schedule. Designing the products in parallel gave us a way to test the foundation against real product needs instead of designing an abstract administrative system.

Core — Institutional structure and administration

Core gave administrators a place to manage the underlying structure that connected products relied on: organizational hierarchy, academic data, workflows, permissions, and other shared configuration.

Schedule — a purpose-built workflow

Schedule used that shared foundation in a very different context. Instead of exposing the administrative machinery, it gave schedulers a focused interface for building schedules, identifying conflicts, and resolving them.

04 — One system, different jobs

For a registrar or administrator, the architecture could be explained simply:

This distinction became an important product principle: put shared complexity in the foundation, then give each product enough freedom to create the experience its users actually need.

05 — Building beyond Schedule

Core was designed to support more than a single scheduling application.

By separating shared data and administrative capabilities from specialized product workflows, we created a foundation that could support additional connected experiences without requiring every product to recreate the same underlying capabilities.

The result wasn't simply a new administrative application. It was a different model for how products across the ecosystem could be built: shared where consistency matters, specialized where the user experience matters.

Next case study:

Turning a complex institutional approval process into an understandable experience for faculty and administrators.