CASE 01: TAKESHAPE API to AI

Introduction

As a founder and CEO at TakeShape, I lead all of our product efforts while wearing multiple hats: product strategist, UX researcher, and hands-on designer. This case study covers how my team and I found and solved a specific problem in enterprise API integration.

In late 2019, after running our headless CMS product for a year, we noticed a problem our customers cared about more than content management. Our enterprise customers were drowning in API integration work. The CMS was one of many services they had to stitch together to build a modern site or app.

That observation turned the product from a headless CMS into an API Mesh platform. It also tracked a wider shift in how enterprises build digital experiences, and the hidden costs of composable architecture.

TakeShape homepage highlighting API Mesh

THE CHALLENGE

In 2019, during a residence at Techstars, I spoke with hundreds of potential customers, from developers to CTOs. The pattern was that teams spent more time writing integration code than building features. One engineering leader put it this way:

“We have eleven different services that all need to talk to each other. Each one has its own API, its own authentication, its own data model. Every time we want to make a change, we have to touch multiple integration points. It’s becoming unsustainable.”

This wasn’t an isolated case. As we dug deeper into our research, we found teams typically juggling 5–12 different services, including:

• Content Management Systems
• Product Information Management
• Order Management
• Customer Data Platforms
• Authentication Services
• Search
• Analytics

Customer research during and after Techstars turned up several layers of difficulty for enterprises adopting composable architecture:

Discovery & Design Process

Our first step was getting the full picture of the integration challenge. While customer interviews had given us the broad strokes, we needed to understand the day-to-day reality of building and maintaining these systems. I embedded myself with several development teams, sitting in on their architecture planning sessions and code reviews.

One technical lead at a major retailer perfectly captured the frustration we heard repeatedly: “We’ve built this same integration layer three times now, for three different projects. Each time we think we’ll make it reusable, but the requirements are just different enough that we end up with another custom solution.”

Mesh ecommerce architecture diagram

The problem was organizational as well as technical. Teams were structured around individual services, making cross-service features particularly painful to implement. A senior developer at a digital agency explained: “When we need to add a feature that touches multiple services, we have to coordinate across three different teams, each with their own priorities and sprint schedules.”

Early Design Explorations

With this deeper understanding, we began exploring solutions. I started with rough sketches, sharing them with our engineering team daily. The fast loop mattered because every design decision carried technical consequences.

API Mesh review screen

Mesh sketch overview complex diagram

Mesh sketch overview simple diagram

Mesh application map diagram

Mesh feature concept map

Mesh product prioritization diagram

Mesh schema feedback traffic light system

One of our early assumptions was that developers would want to write custom resolvers for complex integrations. We built a code editor with real-time validation. It was good engineering, and user testing quickly showed it was the wrong feature.

”This is really powerful,” said one developer during testing, “but I spend enough time writing integration code already. I was hoping this would give me a higher-level way to work with these services.”

API Mesh code schema editor

That feedback changed the approach. Instead of better tools for writing integration code, we needed to remove the need for that code wherever we could. The whole service-composition interface had to be rethought.

API Mesh visual schema editor

Team Dynamics & Decision Making

As a small founding team, we had to be deliberate about process. We instituted daily design reviews where we would share work in progress through Figma. These sessions often turned into collaborative design exercises, with team members sketching alternatives directly in the design file.

Mesh schema editor discussion

The small team size became an advantage. We could move quickly from insight to implementation, often deploying changes the same day we identified issues. However, we needed to ensure this speed didn’t come at the cost of quality.

The design process was light:

• Morning design reviews with engineering
• Afternoon user testing sessions
• End-of-day documentation updates
• Weekly design system audits

This rhythm helped us maintain consistency while moving quickly. When we expanded the team, these practices scaled naturally into more formal design operations.

Test & Iterate

One of our most valuable practices was running weekly testing sessions with developers from our customer organizations. We’d give them a prototype and a real integration task from their backlog.

Animated API Mesh visual design flow

In one session, a developer struggled with our service configuration interface. “I can see all the individual settings,” they said, “but I’ve lost sight of how these services connect at a high level.” That comment led to the visual service mapper, which became central to the platform.

The challenge was balancing simplicity with power. Enterprise developers needed deep technical capabilities, but they also needed to be able to quickly understand and modify their service architecture.

Mesh unified schema discussion

Mesh user flow diagram

Animated API Mesh creation wireframes

Mesh user flow map

Mesh workbench feedback critique

Animated API Mesh onboarding wireframes

Key Findings

Technical Implementation & Challenges

The hard part was building a tool that could handle enterprise complexity and still be approachable. As one of our early customers put it: “We need something powerful enough for our architects but simple enough for our product managers.”

Scaling the Design System

As we added more features, maintaining consistency became increasingly challenging. Our initial component library, built primarily for the service mapper, wasn’t flexible enough for new use cases. We needed a design system that could stretch.

I ran an audit of the interface and reported back to the team.

”We’re seeing the same patterns implemented three different ways,” I shared during a team review. “We need to standardize these interactions, for consistency and for development speed.”

Working with our engineering team, we identified core patterns that we could standardize:

• Service configuration flows
• Authentication interfaces
• Error handling states
• Schema visualization
• Table and list views

The components had to handle edge cases without breaking the shared patterns. Engineers became active participants in design, suggesting changes based on what implementation taught them.

Animated API Mesh UI screens

Measuring Impact

Measuring the impact of design decisions takes both qualitative and quantitative data. We instrumented the platform to see how developers used it.

Some of the data surprised us. While we had spent significant effort optimizing our code editor, usage data showed that most developers preferred our visual tools. “I only drop into the code view for complex edge cases,” explained one user. “The visual interface is faster for 90% of what I need to do.”

Selection of tracked metrics:

• Time to complete the first integration
• Number of successful service connections
• Error rates and resolution times
• Number of onboarding steps completed

But the most meaningful feedback came from our users’ own metrics. A large retail customer reported:

“We’ve reduced our integration development time by 60%. Features that used to take weeks now take days.”

Key Insights

Three things shaped the project:

1. Technical power users still want visual tools when the tools are good. As one architect told us, “I can write the code, but why should I have to?”
2. Enterprise UX covers the whole development experience. Documentation, error messages, and debugging tools are as important as the primary UI.
3. Small, focused teams can move quickly, but you need clear processes to maintain quality. Daily design reviews and weekly system audits helped us maintain consistency while enabling rapid iteration.

Service provider grid

API Mesh Ecommerce example project

What Worked

Five practices made the difference.

One team, not two

Blending design and engineering from day one paid off. Our daily design reviews became working sessions where engineers suggested UX improvements and designers pushed on technical constraints. The solutions got better and everyone had a stake in the user experience.

Continuous User Feedback

Weekly testing with real users saved us from building the wrong things. When developers physically pushed back from the code editor saying, “This is exactly what I’m trying to avoid doing!” we changed direction that week.

Organic Design System

Rather than build a full design system upfront, we started with core components and let patterns emerge from real use. The system grew with the product and reflected how people used it.

The service mapper

The visual service mapper changed how people used the product. One customer said, “I can finally see what I’m building.” Showing the system mattered more than adding features. The map exposed relationships that configuration screens had hidden.

Shared UX Ownership

When backend developers started raising usability concerns unprompted, I knew UX had stopped being the designer’s job alone. That shared ownership was worth more than any single feature.

What Didn’t Work

Not everything went to plan.

Initial Design Assumptions

I had assumed our technical users would want code-based customization. We spent weeks polishing a code editor that most users barely touched. They wanted to write less code, not write it with better tools. Validate the core assumption before spending design time on it.

Complexity Creep

Our first visual editor was too complex. We designed for power users and overwhelmed everyone else. One customer called it “powerful but intimidating.” Even experienced enterprise users want simplicity, and progressive disclosure is how you give it to them in a complex system.

Documentation Approach

The first documentation was complete and unusable. It was organized by system architecture instead of by task, so users could not find what they needed. Watching them fail to find basic information made us rewrite it around the jobs people came to do.

TakeShape documentation site

Premature optimization

I pushed the team to optimize performance before we understood real usage. That added complexity to the backend and the interface for no measured gain. Now we get the baseline working first and optimize against actual behavior.

Slow to respond to the market

When Shopify expanded into our space in 2023, we were slow to respond. Instead of adjusting, we doubled down on the existing direction. The lesson was to reassess the competition on a schedule, not only when it forces the issue.

Solution Scope

We designed for specific technical use cases when enterprises wanted an end-to-end solution for their whole workflow. Good UX leadership means understanding the full business context, and we came to that understanding later than we should have.

Initial Assumptions

• Overestimated users’ willingness to write custom resolvers
• The first version of the visual editor proved too complex
• The initial documentation approach was too technical
• The performance optimizations were too early in the development process.

Market Challenges

• Shopify’s expansion into the space changed market dynamics
• The enterprise needs exceeded our narrow solution focus
• The initial pricing model needed adjustment
• Marketing message required refinement

Evolution to AI Platform

The API Mesh work led directly to AI agents. We had learned how enterprises manage distributed systems and data flows, and we saw an opening to help them build agents grounded in that data and governed by their own business rules.

At a 2024 customer advisory board meeting, a new pattern showed up. Customers were trying to build reliable AI agents that could work with their distributed services, and struggling.

”We have all these services working together through TakeShape,” one customer explained, “but now we need to make them accessible to AI agents. The complexity is overwhelming.”

TakeShape AI Agent editor

That became the current focus, building and deploying AI agents on top of a combined data mesh. The technical challenges differ, but the core problem is the same one as before. Manage the complexity without losing reliability or control.

We are using the same design process that worked for the API Mesh:

• Regular user testing sessions
• Rapid prototyping and iteration
• Close collaboration between design and engineering
• Continuous measurement and refinement

The AI agent work builds on the API Mesh platform. The goal is for enterprises to build and run secure agents grounded in their data and governed by their business rules.

TakeShape homepage highlighting AI Agents

Three initiatives are on the roadmap.

Next features

• AI-powered API discovery, which maps and documents an enterprise’s data sources automatically
• A visual agent builder for designing and deploying agents without ML expertise
• Guardrails, with security, compliance, and governance controls built in

TakeShape Agent Editor showing philosopher's debate

The visual agent builder is the center of the next releases. Teams assemble agents in a drag-and-drop interface, with a code path kept open for custom work.

The bet is that API orchestration and AI agents belong in one platform. The mesh already knows how the enterprise’s services connect, and an agent needs exactly that knowledge to act safely.

Google Vertex Service Connection for TakeShape

The job is the same as it was in 2019. Give development teams tools that make a complex system simpler to work with.