Secure App IX: A Collaborative API Development System
SAIX was cancelled before most of it shipped. That's not the story. The card patterns, the Integrations detail page, and the Collaboration Spaces concept all got absorbed into TAP's Spaces, which became the headline feature of Tanzu Platform 10. I was the lead designer for Spaces, which meant I was also the person deciding what from SAIX was worth keeping. The work was structured well enough to survive the gap. What I hadn't written down was the reasoning behind the decisions, and when Spaces started, I was the only one who remembered it.
I was responsible for Project Landing Page, Collaboration Spaces, Dev Spaces, Activity Feed, API Runtimes, and Integrations. I co-designed the overall product hierarchy (Projects, Collaboration Spaces, Dev Spaces, API Runtimes) and built the card/list view pattern that carried through the whole product. I delivered a click-through prototype for VMware Explore 2022. API Validation and Scoring was primarily my fellow designer's work. I was secondary on that section.
In the end, only the collaboration popover and API scoring/validation made it into TSM Enterprise production. TSM and other Tanzu products were being merged into Tanzu Application Platform, so development on SAIX stopped. The hierarchy I designed, the patterns, and the Integrations detail page were absorbed into TAP's Spaces and became the foundation I built from when I joined that project.
Many SAIX features and concepts were incorporated into TAP and became the root of the design for Spaces. The Integrations detail page specifically became the foundation for Profiles and Traits detail pages in Spaces.
A collaborative API development system.
Secure App IX (SAIX) was originally envisioned as a new feature in Tanzu Service Mesh (TSM) that let developers collaborate on API development while still taking advantage of the power and security TSM provided. With a VS Code plugin, users could collaborate on whatever platform they worked best in.
The context: Mesh7 and TSM Enterprise
VMware acquired Mesh7 in March 2021, six months before I joined the TSM team. Mesh7 had built a contextual API behavior security solution based on Envoy. It could monitor application behavior at the Layer 7 API level, detect drift from normal API communication patterns, and flag risks in real time.
My first month on the team, our PM announced VMware Tanzu Service Mesh Enterprise, which integrated Mesh7's technology into TSM. TSM Enterprise could auto-discover APIs, learn baseline behaviors, detect deviations, and enforce granular security policies: OWASP API Top 10 defense, schema validation, PII detection, geofencing, and egress controls.
SAIX was the developer-facing product being built on top of that engine. TSM Enterprise gave operators the security and observability layer. SAIX was supposed to give developers the collaborative workspace to build, test, and manage their APIs within that secure environment, without needing to understand the underlying infrastructure.
Much of what was designed for SAIX became the basis for Tanzu Application Platform's Spaces.
TSM Enterprise gave security teams deep API observability. SAIX was about giving developers a place to work inside that security context. Three design tensions shaped the work:
| 01 | How do you surface everything a developer needs for API work without building another IDE? |
| 02 | How do you integrate version control without owning the git workflow? |
| 03 | How do you present API runtimes and cluster assignments in a way that's actionable rather than just informational? |
Before any of the surfaces were finalized, I built a click-through prototype to establish the product hierarchy and test how users would navigate between Projects, Collaboration Spaces, Dev Spaces, and API Runtimes. This helped the team align on structure early and gave us something concrete to pressure-test with stakeholders before committing to high-fidelity screens.
The prototype also became a conference artifact. We used an evolved version of it for VMware Explore 2022 to demonstrate the SAIX vision to customers and prospects.
The landing page had one hard constraint that shaped the whole design: Projects had to be completely information-isolated from each other. Some of TSM's clients were healthcare organizations, and the platform was built for regulated industries. PII detection, data sovereignty controls, egress controls were core to why those customers were there. Project isolation wasn't a UX preference. It was a compliance requirement.
I based the card design on TSM's Global Namespace card. GNS was TSM's foundational construct for applying policies across multi-cloud environments, and keeping visual continuity made sense since SAIX was a feature inside TSM Enterprise. Rather than showing GNS metrics and a topology, the SAIX card showed Collaboration Space members, Dev Space count and status, and unread messages. I also added a list view with the same data in a more compact format. That pattern carried through the entire product.
Card view — member count, Dev Space status, unread messages
List view — same information in a compact format
The Collaboration Space was the most structurally complex section to design. I worked out the information hierarchy across Dev Spaces, API Runtimes, and the Activity Feed, and figured out how those three things coexisted on one screen without competing for attention. The Activity Feed lived in a pane along the bottom rather than a side panel or a separate tab, accessible and contextual without taking over the primary workspace. I also designed the empty states for each section, which mattered more here than in most places. A new Collaboration Space genuinely is empty, and users needed to understand what they were looking at before anything had been added.
Collaboration Space — Dev Spaces, API Runtimes, and Activity Feed in one view
Dev Space was one of the largest sections in SAIX. It was the primary workspace where developers actually built their APIs, which meant it had to do a lot. I designed it to handle multiple branches, surface everything a developer needed to know about the API they were working on, and stay flexible rather than rigid. Developer workflows aren't linear, and the UI needed to reflect that without becoming overwhelming.
Dev Space card inventory
Dev Space detail — API builds, repo pushes, and validation
The Activity Feed needed to be available everywhere in SAIX without requiring users to navigate to a dedicated screen. I built three access points: a section on the Collaboration Space showing the newest messages, a full dedicated screen for the complete history, and a popout accessible from the upper right corner of every screen and dismissible at any time.
The reasoning behind the popout was that developers needed to check activity context without losing their place. A dedicated screen would break flow. The popout solved it without requiring any navigation at all. It was one of the two SAIX features that made it to TSM Enterprise production.
Activity Feed embedded in the Collaboration Space
Full Activity Feed and popout view
API Validation was primarily my fellow designer's work. I was secondary on this section. The validation engine came from the Mesh7 acquisition. It tested APIs against OWASP API Top 10 vulnerabilities, validated against schema specs, and detected PII in real time. Scores displayed as a badge at the top of the screen and in the tab itself, so the security status was visible without having to dig for it. API scoring and validation was the second SAIX feature that shipped to TSM Enterprise production.
API validation — OWASP scoring, schema validation results, and PII detection
I adapted API Runtimes directly from TSM's cluster design, essentially a lift and shift into the SAIX context. The underlying concept was familiar enough from TSM that it didn't require significant redesign, just translation into SAIX's hierarchy.
API Runtime route popup — cluster assignment and default runtime
The Integrations section reused TSM's existing Integrations feature directly. If a user had already set up Integrations in TSM, they worked in SAIX too, which is one of the reasons I recommended connecting each SAIX project to an existing TSM project wherever possible.
The one addition was GitHub. Since SAIX was built around git ops, each Project needed an active GitHub account configured. The detail page showed configuration and connection status (Connected/Disconnected), with status also surfaced on the card so admins could catch issues without navigating into the detail. Multiple accounts were supported per Project.
The Integrations detail page became the foundation for the Profiles and Traits detail pages in Spaces.
Integrations card list — status visible at a glance
Integration detail — configuration and connection status
Not all of SAIX made it into TSM Enterprise. In the end, the collaboration popover and the API scoring and validation were all that went to production. TSM and other Tanzu products were being merged into the Tanzu Application Platform (TAP), so development on SAIX stopped.
Many features and concepts from SAIX were incorporated into TAP and became the root of the design for Spaces.
| SAIX Surface | What It Became |
|---|---|
| Collaboration popover | Shipped to TSM Enterprise in production. |
| API Validation and Scoring | Shipped to TSM Enterprise in production. |
| Collaboration Spaces concept | Became the root concept for TAP Spaces, the central abstraction model for Tanzu Platform 10. |
| Integrations detail page | Became the direct foundation for Profiles and Traits detail pages in Spaces. |
| Project hierarchy | Informed the Spaces IA in TAP, with Spaces referencing Availability Targets and Profiles instead of Dev Spaces. |
| Card and list view pattern | Carried forward throughout the Spaces design system. |
Most of SAIX never shipped. The Collaboration Spaces concept, the card/list pattern, the Integrations detail page — none of that went to production in TSM Enterprise. All of it ended up in Spaces, built by a team that wasn't there for the original decisions.
That only works if the design is structured well enough to be readable without the designer in the room. The hierarchy decisions were clear enough that they could be inherited. What wasn't documented was the reasoning behind them: why Projects were isolated, why I based the card on GNS, why the popout over a dedicated screen. I would have written that down earlier if I'd known I was handing off to a team I'd never meet.