I’ve been focused on establishing the design language for the entire product, aligning it with Mozilla’s updated visual identity, leading the design team as a Monoface™ founder, and engaging in design process directly.

Mozilla ran plenty of experiments around artificial intelligence (some of which we had a chance to take part in), and one of the most successful turned out to be its investment in API infrastructure.

In the AI-revolution era, when a “gold rush” hits, the shovel manufacturers produce the tools without which the gold simply couldn’t be mined. Almost every day you see more and more products shipped and AI features added, and all of them, small and large, rely on existing solutions rather than their own technologies.

We joined Tabstack while the team was still making its core technical decisions, so we used that time to understand deeply what the product was going to solve, and how. Extensive meetings with Jacob, Nick, and Stafford (the backbone of the team) helped us build a precise picture.

The most interesting part is that even though OpenAI and Claude already have their own APIs, Tabstack is a fundamentally different category of product, so comparing them head-to-head doesn’t quite work.

The Tabstack API is a web content extraction and transformation toolkit built specifically for AI-agent developers. It provides intelligent web-scraping capabilities, content processing, and structured data extraction through a simple REST API.

Your AI Agent (Claude / GPT)

Decides WHAT to do.

High-level task, e.g. “find top 3 repos, extract name + stars”

Tabstack API acts in the web:

(1) Discovery

Find the right pages to visit (powered by Parallel Search API)

(2) Execution

(Tabstack’s own infrastructure)

Spin up headless browser; render JavaScript / SPAs; navigate, click, scroll, fill forms; adapt when pages are messy or inconsistent.

(3) Transform

Turn raw web content into clean data → Markdown / JSON / custom schema.

Clean structured data

Back to your agent (Claude / GPT)

Uses the result to reason / decide the next step.

So, long story short: the OpenAI / Claude API is the brain. You send it a prompt and get back reasoning, text, and tool calls. But the model itself can’t go out onto the internet and interact with live pages (rendering, JavaScript, forms) — that’s outside its scope.

Tabstack is the eyes and hands. It takes on all the complexity of orchestrating headless browsers, rendering JavaScript, and adaptively interacting with pages, so the developer can focus on agent logic instead of browser infrastructure. The output is clean, structured data: Markdown, JSON, or custom schemas.

As a result, they work together, where the brain decides what to do, and Tabstack goes and does it on the web.

Tabstack serves a chain of three users, each with their own pain and their own level of access to the product. One builds agents and wants to be rid of infrastructure overhead, another makes the adoption decision and weighs the risks, and the third doesn’t write code at all and reaches Tabstack only through a layer built on top of it.

The core audience. These people build AI agents and hit the same wall every time: the model reasons perfectly in a sandbox, but the moment it’s connected to the live web, the developer stops building the agent and starts maintaining infrastructure: headless browsers, SPA rendering, login flows, forms, and breaking selectors. As a result, a simple script turns into full-time work. Tabstack removes this hidden tax → the agent logic stays with the developer, and the messy browser infrastructure moves behind a single API.

(U1) User 1

The Agent Builder

Dev / AI engineer
*Core audience*

[!] Pain:

The model reasons correctly in a sandbox but cannot operate on the live web.

Connecting it requires building and maintaining browser infrastructure: headless browser orchestration, SPA rendering and JavaScript execution, login flows, CAPTCHA handling, and selectors that break on page changes.

A single-purpose fetch script expands into ongoing infrastructure work unrelated to the agent itself.

[→] Tabstack gives:

A single API that handles the browser layer. The developer retains the agent logic (reasoning, decisions, task definition) and delegates execution: rendering, navigation, clicks, form fills, and recovery on inconsistent pages.

Output returns as Markdown, JSON, or a custom schema, consumable directly by the agent. No browser fleet to operate, no infrastructure to maintain.

Access: Direct

They have engineers, but engineering time is expensive, and the browsing layer isn’t a core task. Building and maintaining it in-house means months of work on something that delivers no direct value to their own users, plus legal and reputational risk in how third-party data is handled. Tabstack gives them ready infrastructure out of the box, and Mozilla’s privacy positioning works as insurance in front of their own clients — nonprofit backing and ephemeral data handling become a real argument for an enterprise buyer rather than marketing.

(U2) User 2

The Pragmatic Founder

Founder / Team A-B

[!] Pain:

The team has engineers, but engineering time is costly and the browsing layer is non-core. Building it in-house requires months of work on infrastructure that delivers no direct user value and requires continuous maintenance as web targets change.

It also carries operational risk: how third-party sites are crawled, how retrieved data is handled and stored, and how that exposes them to their own clients and to publishers.

[→] Tabstack gives:

Managed browser infrastructure out of the box, freeing budget for the product rather than the execution layer.

It also ships with Mozilla’s privacy model: strict data minimization, ephemeral handling with content purged after each task, a dedicated Mozilla Tabstack User-Agent, honored robots.txt opt-outs, and no training on customer data.

For an enterprise buyer evaluating data handling, this is a procurement argument, not marketing.

Access: Mixed

They need an outcome (pull competitor data, monitor prices, automate research) but they can’t program. The important nuance: Tabstack itself isn’t for them directly. It’s an API, not an application with buttons. They reach it indirectly, through a developer intermediary or a no-code platform (like UBOS) that wraps Tabstack in a visual interface. This segment extends reach, but always through a layer on top.

(U3) User 3

The Non-Technical Business Owner

Business owner

[!] Pain:

Requires a defined web output (competitor data, price and stock monitoring, lead lists, automated research) without the ability to write the code to produce it.

Available options are hiring a developer, assembling no-code tools, or manual work. Each is slow, costly, or unreliable, and none scales with the business.

[→] Tabstack gives:

No direct access.

Tabstack is an API, so this user does not interact with it directly. Access occurs through a layer built on top: a contracted developer, or a no-code / AI-agent platform (e.g. UBOS) that wraps Tabstack behind a visual interface.

It extends Tabstack’s reach without being a direct user, which makes the surrounding interface and partner ecosystem as relevant as the API.

Access: Indirect

Conclusion: Thus the product must provide the full set of functionality and information to cover both the advanced engineer (API key management, and a playground for testing endpoints across different scenarios before integration) and the founder / operator (team management, spend tracking, simple and legible key management, and clear usage monitoring).

On entering Tabstack, the user will try to:

Action

User(s)

Priority

Test endpoints on Playground

U1, U2

Create API keys

All

!!!

Overview & manage API keys

All

!!!

Overview & manage the usage

All

!!!

Briefly overview everything on the high-level

All

Jump to Documentation

(to explore essential and case-specific questions)

U1, U2

Set up and manage the team

All

Manage plans & billing

All

!!!

Manage account

All

Navigation / sitemap: After getting clarity on who our users are, and exploring the existing products on the market, we came to the conclusion that there’s no need to reinvent the wheel when it comes to navigation.

Tabstack Console

Home

Management

Usage!!!

API Keys!!!

Team

Billing!!!

Playground

Extract

Generate

Automate

Research

Documentation↗

Quickstart↗

API Documentation↗

Account Management

Settings

The established structure covers all the basic scenarios and is flexible enough to expand as new features and links arrive.

The design phase began right after the large Mozilla brand update, so we had a good chance to establish the product’s foundation on Mozilla’s fresh tone and a brand-new typeface (what a piece of art!).

At the same time, we agreed on one rule: this boldness shouldn’t get in the way of the user’s ability to interact with Tabstack effortlessly, and we checked against that rule every time we had concerns.

Font System

First, for the font system, we decided to go with a duo-family solution, where the Mozilla typeface applies for headlines, and Geist + Geist Mono for body text and captions. This decision came after experimenting with different variations: the Mozilla font family works perfectly in marketing materials, including websites, but should be used carefully in product interfaces (especially for body text and captions) due to its highly detailed geometry.

The chosen combination of font families provides both strong Mozilla brand continuity and stable text accessibility across all Tabstack interfaces.

Form & Function Alignment

While design is a creative space where designers have the freedom to define how elements look and feel in each particular situation, we are still serious about how the interface communicates with the user through its form. By aligning an element’s shape with its function, we build repetitive patterns that significantly reduce cognitive load over the long run of everyday use.

Sharp shapes:

For charts & graphical elements

Rounded shapes:

For action elements

Semi-rounded shapes:

For input/output/navigation elements

Mozilla’s brand has a "sharp" identity, a warm nostalgia for 90s/00s simplicity paired with future-oriented visual precision. It’s a bold foundation for marketing, while for product interfaces our recommendation was to act more carefully, with a clear form-to-function correlation.

Color System

As with many of the interfaces we’ve designed, we kept the color system on Tabstack as simple as possible. The solution is an accent-duo + black-and-white primitives, shaded through opacity rather than plain color.

Excluding plain color shading was intentional. As a trade-off, we gave up fine-grained control over each individual color token (with plain coloring you can make the 500 token "a bit more orange" than the 600) in exchange for overall color-system integrity and stability — creating resilience to regular updates and changes.

Example: with a plain-based approach, a designer aligns color tokens with the interface, micro-balancing details, but after updating a few background elevations, finds that several subtle button fills no longer pass a contrast check. Because the color system is plain, the colors don’t blend at all when overlaid. With an opacity-based approach, the whole system is fluid, reacting flexibly to changes, which makes it resilient to most updates.

Additionally, if there’s a need to avoid color blending, tokens can be layered inside a single element to get the right effect. For example, accent-pink__o40 (FF97EA 40%) can be placed on top of the white__o100 (FFFFFF 100%) layer, and the output will equal the plain color FFD5F7, which won’t blend with the colors beneath it.

More than that, the real magic happens when you blend accent colors with each other (accent-pink__o50 + accent-purple__o80 → BA70F5 — an entirely new color variation, without adding extra tokens or needlessly expanding the color system).

We designed the Tabstack console not only to efficiently cover current user needs, but also to be ready for flexible, natural product expansion. In the UI system, each feature / cell / output is a module that can be added or removed without affecting the existing structure. This configuration is highly adaptive to different contexts: from the initial interaction with the product, to everyday API management, to tracking situational events and errors.

Also, when the user interacts with Tabstack, the interface doesn’t go to extremes — it neither shows all the available functionality at once,¹,² nor condenses everything into rails-based flows.³ Instead, it highlights the next essential steps, briefly conveying what a particular feature does and how it works, while keeping everything open for manual exploration.

It doesn’t matter whether the user just joined Tabstack or has been using it for a while, they can always test Tabstack endpoints, read the documentation, invite the team, or simply explore the product before taking action.

Tabstack is an API, which means it already requires specific actions and technical understanding outside the console, so there’s no reason to make users feel frustrated when acting inside it.

(Home / Overview Panel) Getting started

(Home / Overview Panel) API key added

(Home / Overview Panel) First usage metrics

(Home / Overview Panel) Extended usage metrics with errors

(Usage / Chart) Getting started

(Usage / Chart) API key added

(Usage / Chart) First usage metrics

(Usage / Chart) Extended usage metrics with errors

(Usage / Table) Request groups list

(Usage / Table) Expanded request group

(Usage / Table) Hovered request cell

(Usage / Table) Expanded request group with errors

(Playground) Testing the Automate endpoint; Creating a task

(Playground) Testing the Automate endpoint; Task initiation

(Playground) Testing the Automate endpoint; Exploring content

(Playground) Testing the Automate endpoint; Completing

(API Keys / Table) API keys overview

(Create an API Key) Modal window

(Create an API Key) Entering name

(Create an API Key) Success

(Team / Table) Users overview

(Team / Table) Sending an invitation; Entering email

(Team / Table) Invitation sent

Tabstack lets an AI agent act on the open web and return the result as clean data, so the builder doesn’t have to run browser infrastructure to ship. It’s at an early Alpha stage, and while this study documents the reasoning behind the design, I’ll add usage metrics and links once there’s data worth sharing.

Stay tuned!