Designing a local-first API platform from scratch.

I joined Requestly as the founding designer and owned the product design end to end. That included the API client, testing and debugging workflows, network tools, AI features, and the design system. I still lead design for it at BrowserStack.

Role

Founding product designer

What I designed

API client, testing, mocking, debugging, and AI features

Company

Requestly, now part of BrowserStack

Built around

Local files, Git workflows, and one desktop workspace

Impact

Reduced tool switching across testing, mocking, and live traffic

Goals

We wanted developers to design, test, mock, and debug APIs in one place. Collections would stay as local files that work with Git, so teams could use their existing workflow without creating another cloud account.

Quick background

Requestly already helped developers intercept and mock HTTP traffic. But when they needed to send a request, inspect a response, or run a test, they often had to leave Requestly and open another tool.

At the same time, popular API clients were moving local work into the cloud and asking people to sign in before sending a basic request. We saw a chance to connect API testing, mocking, and traffic inspection in one platform. We started with a desktop app built around local files.

The problems

Work was split across tools: Developers used Requestly to intercept or mock traffic, then moved to another app to send requests and test responses.

Less control over API data: Other clients were removing local scratchpads and pushing collections into cloud accounts.

Switching took too much work: Moving from another client often meant rebuilding collections, environments, and requests by hand.

The workflow felt disconnected: Requests, tests, mocks, and live network traffic did not share one clear place to work.

Key product decisions

Keep collections as local files: Collections are saved as plain files on the developer's machine. Teams can version, review, and share them through the Git workflow they already use.

Connect the whole API workflow: The API client, test runner, mocks, and network inspector belong in the same workspace. A captured request can become something a developer can edit, save, test, and reuse.

Keep the workspace dense but readable: Headers, parameters, auth, scripts, and responses all compete for space. I used clear groups, flexible panels, and visible error states so developers can scan the screen without losing context.

Make switching easy: Developers can bring in existing collections or cURL commands and start working without recreating everything first.

Import & first run

Importing an existing collection is the quickest way to get started. Developers can choose what to bring in, review duplicate collections, and avoid overwriting work by mistake.

Import data modal selecting which collections to bring in

Warning when imported collections already exist in the workspace

Request testing

This is the main place for sending requests and reading responses. I gave the response more room and used flexible split panels so large JSON bodies stay readable on smaller laptops. Scripts, history, and save actions stay close without getting in the way.

Empty workspace before any request has been created

New request editor with empty params and response panel

Collection overview documentation for a sample API

Pre-request script editor before the request has been run

Response body after sending a request, shown alongside the request builder

Save request modal for naming a request and choosing a collection

Clear history confirmation for deleting requests from a date

Collection runner

Developers can choose which requests to run and follow pass, fail, and skip results as the collection runs. The results stay in the same workspace as the requests and tests.

A collection run in progress, with results streaming in

A collection run configured for multiple iterations, with advanced run settings

Collection runner with configuration and pass, fail, and skip results

Network inspector

The network inspector brings live traffic into the same window as the API client. Developers can open a call, check its headers and variables, and use it in their API work without changing tools.

Network panel empty state before any request traffic

Network panel listing API calls alongside an open request

Inspecting headers of a request from the network panel

Network panel with the Variables tab open for a selected request

GraphQL

The GraphQL editor can fetch a schema, browse fields, manage variables, and show validation errors while a query is being written. REST and GraphQL work stays in the same place.

GraphQL editor fetching schema from a GraphQL endpoint

Toast prompting a schema refresh after the GraphQL URL changes

GraphQL schema explorer with selectable fields after the schema loads

GraphQL query and variables editor with the schema explorer open

GraphQL validation catching a field that does not exist on the type

AI assistant

I designed an assistant that can create collections, edit requests, and write tests from a simple prompt. It understands the open workspace, shows the proposed changes, and waits for approval before updating anything.

Requestly AI panel with entry prompts to explore APIs and generate tests

Natural-language question about the IAAM collection with the assistant processing a reply

Generated collection overview and a follow-up question about Invite User API parameters

Assistant explaining Invite to Group parameters with an option to open the API request

Adding webpage and YAML file sources as context for the AI chat

AI-generated request and response JSON samples with create-example actions

Generated JavaScript fetch snippet for a Stack Exchange API request

Impact & reception

Community reviews

Developers and community reviewers began sharing the product on their own. Many described it as a faster, cleaner alternative to the heavier tools they had been using.

Onboarding with no signup

Developers can open the app, import a collection, and send a request without creating an account first.

More control over API data

Local collection files gave teams a clear way to keep API work on their own machines and manage it through Git.

One connected API workflow

Request testing, automated runs, mocking, and live traffic now sit together instead of being split across separate tools.