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 details how my team and I identified and solved a critical challenge in enterprise API integration.

In late 2019, after running our headless CMS product for a year, we noticed a recurring challenge faced by our user base that was more urgent than content management: our enterprise customers were drowning in API integration complexity. While our CMS solved one piece of the puzzle, it was just one of many services they needed to build modern digital experiences.

Original TakeShape homepage highlighting CMS

This observation would transform our product from a headless CMS to an API Mesh platform, an evolution that reflects a fundamental shift in how enterprises are building digital experiences today and the hidden costs of composable architecture.

TakeShape homepage highlighting API Mesh

THE CHALLENGE

In 2019, during a residence at Techstars, I had the opportunity to speak with hundreds of potential customers, from developers to CTOs. A pattern quickly emerged: teams were spending more time writing integration code than building actual business features. One conversation with an engineering leader particularly stood out:

“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

Through extensive customer research during Techstars and beyond, we uncovered several layers of challenges facing 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 challenge wasn’t just technical; it was organizational. 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. This rapid feedback loop was crucial since every design decision had significant technical implications.

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 sophisticated code editor with real-time validation. The technical implementation was impressive, but user testing quickly revealed a problem.

”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

This feedback led to a fundamental pivot in our approach. Instead of providing better tools for writing integration code, we needed to eliminate the need for that code entirely where possible. This meant rethinking our entire interface for service composition.

API Mesh visual schema editor

Team Dynamics & Decision Making

As a small founding team, we had to be extremely deliberate about our design and development 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

Our small team size actually 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.

I established a lightweight but effective design process:

• 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

During one particularly enlightening 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.” This led us to develop our visual service mapper—a tool that would become central to our 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

Our biggest technical challenge wasn’t just building a tool, it was building a tool that could handle the complexity of enterprise systems while remaining 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 initiated a comprehensive audit of our interface:

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

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 key was making these components flexible enough to handle edge cases while maintaining a consistent user experience. Our engineers became active participants in the design process, suggesting improvements based on implementation realities.

Animated API Mesh UI screens

Measuring Impact

Understanding the impact of our design decisions requires both qualitative and quantitative metrics. We implemented a comprehensive monitoring system to track how developers were using the platform.

Some key findings 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

Looking back, several crucial insights shaped our project:

1. Technical power users still appreciate visual tools when thoughtfully designed. As one architect told us, “I can write the code, but why should I have to?”
2. Enterprise UX isn’t just about the interface—it’s about the entire 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

Looking back at what really made a difference, I found that our success came down to several key approaches that transformed how we built the product.

Breaking Down Silos

I found that blending design and engineering teams from day one was transformative. Our daily design reviews became collaborative sessions where engineers suggested UX improvements and designers challenged technical constraints. This cross-pollination led to better solutions and increased everyone’s investment in the user experience.

Continuous User Feedback

Weekly testing with real users saved us from building the wrong things. When we saw developers physically push away from our code editor saying, “This is exactly what I’m trying to avoid doing!” we immediately pivoted our approach. These regular touchpoints helped us catch misalignment early and adjust course quickly.

Organic Design System

Rather than building a comprehensive system upfront, we started with core components and let patterns emerge naturally from real use cases. This approach gave us a practical system that evolved with our product and reflected how people actually used it.

Visualization Breakthroughs

Our visual service mapper revolutionized the user experience. When one customer said, ‘I can finally see what I’m building,’ it confirmed that visualizing complex systems mattered more than adding features. These visualizations revealed relationships that configuration screens previously obscured.

Shared UX Ownership

Creating an environment where everyone felt responsible for the user experience multiplied our effectiveness. When backend developers started raising usability concerns unprompted, I knew we’d built a culture where UX wasn’t just the designer’s job. This collective ownership became our competitive edge.

What Didn’t Work

Not everything went according to plan, and these challenges taught me valuable lessons about UX leadership and product development.

Initial Design Assumptions

I had assumed our technical users would want powerful code-based customization. We spent weeks perfecting a robust code editor that most users barely touched. They actually wanted to avoid writing more code, not have better tools for it. This taught me to validate core assumptions with users before investing significant design resources.

Complexity Creep

Our first visual editor was too complex—we designed for power users but overwhelmed everyone else. One customer described it as “powerful but intimidating.” I learned that even sophisticated enterprise users appreciate simplicity and that progressive disclosure is essential when designing complex systems.

Documentation Approach

We initially created documentation that was technically comprehensive but practically unusable. Users couldn’t find what they needed because we organized it by system architecture instead of common tasks. Watching users struggle to find basic information forced us to completely rethink our approach to UX writing and information architecture.

TakeShape documentation site

Preemptive Optimization

I initially pushed the team to optimize performance before we understood real usage patterns. This led to unnecessary complexity in both the backend and the interface. A better approach we now follow is to establish baseline functionality first, then optimizing based on actual user behavior and pain points.

Market Adaptability

When Shopify unexpectedly expanded into our space in ‘23, we were slow to adapt our strategy. Instead of pivoting quickly, we doubled down on our existing direction. This taught me the importance of maintaining design flexibility and regularly reassessing the competitive landscape to inform UX decisions.

Solution Scope

We initially designed for specific technical use cases rather than broader enterprise needs. What enterprises actually wanted was an end-to-end solution that addressed their entire workflow, not just isolated parts. This experience reinforced that good UX leadership requires understanding the full business context, not just the immediate design challenges.

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 insights from our API Mesh phase directly informed our evolution toward AI Agents. Having learned crucial lessons about how enterprises manage distributed systems and data flows, we saw an opportunity to help them build secure agents grounded in their data and governed by their business rules.

During a 2024 customer advisory board meeting, a pattern emerged. Our enterprise customers were struggling with a new challenge: building reliable AI agents that could interact with their distributed services.

”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

This led to our current focus: making it as easy to build and deploy AI agents on top of a combined data mesh. The technical challenges are different, but the core problem is similar: managing complexity while maintaining reliability and control.

And we’re applying the same user-centered 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

Building on our success with the API Mesh platform, we’re embarking on an ambitious new chapter focused on AI Agents—enabling enterprises to build and run secure agents grounded in their data, governed by their business rules, and designed to drive real business value.

TakeShape homepage highlighting AI Agents

Our roadmap outlines key initiatives that will reshape how teams build and deploy AI-powered applications:

Next Generation Features:

• AI-Powered API Discovery: Automatic mapping and documentation of enterprise data landscapes
• Visual Agent Builder: Intuitive interface for designing and deploying AI agents without ML expertise
• Enterprise-Grade AI Guardrails: Built-in security, compliance, and governance controls for AI operations

TakeShape Agent Editor showing philosopher's debate

The cornerstone of our upcoming releases is the Visual Agent Builder, democratizing AI development across organizations. This tool enables teams to create sophisticated AI agents through an intuitive drag-and-drop interface while preserving the flexibility needed for custom implementations.

Looking ahead, we see immense potential in merging API orchestration with artificial intelligence. Our platform will bridge enterprise data systems and the emerging world of AI agents, enabling organizations to build intelligent, automated workflows previously out of reach.

Google Vertex Service Connection for TakeShape

As we advance, we remain focused on empowering development teams with tools that simplify complex systems and make AI accessible. The future of enterprise software development is collaborative, visual, and AI-enhanced. We are building the platform to make that future a reality.