The Pod — Julia Goncalves

Context

The traditional pipeline wasn't built for uncertainty

Pipefy is used by large enterprises — Accenture, Itaú Bank, BTG Pactual — to automate operational workflows. These customers rely on the product for audit, compliance, and process governance. The stakes are high, which makes the traditional dev cycle feel necessary. But it also makes it slow.

A standard feature cycle at Pipefy goes from discovery to Figma to refinement to development to QA to release. For features with clear requirements and known solutions, that's the right process. For uncertain hypotheses — where the question isn't how to build but whether to build — that pipeline has too much latency. By the time you've gone through it, you've invested months in something you could have validated in days.

The pod was built on a single premise: validation doesn't require a full product cycle.

The experiments we ran lived in the context of Control Plane — an internal strategic bet that the real differentiator in process management software is observability. Not just running processes, but understanding them. Seeing what happened to an item, how a process is configured, and how processes relate to each other.

The Format

A 3-person team. A 10-day clock. No Figma.

The pod is a small, autonomous unit: one designer, one PM, one developer. We operate in 10-day cycles — from hypothesis to validated experiment. If users confirm the value, the feature enters the traditional dev pipeline for refinement and scaling. If not, the experiment is archived with documented learnings, and we move on.

What we explicitly left out:

—

No Figma

The design system already lived in the codebase. With full access to the production repo, the handoff step became unnecessary — decisions happened in the code, where the design system was already enforced.

—

No product docs

No PRDs, no requirement documents. The hypothesis is the brief.

—

No dev refinement

No sprint ceremonies, no ticket grooming, no estimation rituals.

✓

Real users, real product

Beta tags and feature flags ship experiments directly into the live product. Feedback is behavioral, not self-reported.

When something ships from the pod, it ships as a branch — kept separate from main — with a beta tag. Users who opt in are interviewed by the pod: we go deep with them on value, comprehension, and behavior. They see the feature in their actual workflow, in production. There's no test environment, no prototype — just the real thing, gated by a flag.

How We Built

Claude Code CLI as the medium, not the shortcut

Every experiment was built using Claude Code CLI — Anthropic's command-line tool for AI-assisted development — directly against Pipefy's production codebase in React + TypeScript. As the designer on the pod, I had full access to the codebase: I could navigate data structures, locate existing components, and reference the Lumen design system as it lived in the repo. Figma handoff became obsolete — not because quality dropped, but because the source of truth moved from a design file to the production environment itself.

This isn't "AI generates code while the designer reviews." The model is different: I built the features myself, using Claude Code as a development collaborator. The AI navigated the codebase, maintained consistency with team patterns, and handled implementation mechanics. I held all product and design decisions — and applied the design system directly as I worked.

Every experiment followed the same workflow:

1

Context — framing the experiment for Claude

I opened each cycle by giving Claude the context of the experiment: the hypothesis, the user problem, the scope. Not a spec — a conversation that aligned the session before any code was touched.

2

Discovery — searching what already existed

Together we searched the codebase: what components already existed, what APIs were available, what was missing. Full codebase access meant I could see the real landscape — not a simplified diagram — before making any decisions.

3

Planning — before writing a single line

Only after mapping what existed and what didn't did we plan. Data structures, component architecture, integration points — defined in full before development started.

4

Building — with the design system as the standard

I built the first functional version of each experiment, applying Lumen design tokens and patterns directly as I worked. Speed came from removing process overhead — not from skipping quality. All 3 experiments shipped with TypeScript strict mode, unit tests, and full i18n in Portuguese, English, and Spanish from day one.

5

Handoff — developer adjusts and deploys

Once the first functional version was ready, the developer entered to fix small bugs and wrap the feature in a feature flag. That's what put it in front of real users — not a staging environment, but the live product, gated by a beta tag.

The Experiments

Three visualizations. One vision: giving process a body.

Each experiment targeted a different dimension of the observability problem: the history of a single item, the map of a single process, and the relationships between processes.

01 — Card Timeline The history of an item

The problem: A card in Pipefy can pass through dozens of phases, be moved by automations, have fields filled by AI agents, receive comments, emails, and approvals — all mixed in an unstructured feed. For an auditor, making sense of the narrative was nearly impossible.

What we built: A visual, chronological timeline of a card's entire life, divided into three parallel lanes: human actions, automations, and AI agents. Each process phase is a visual anchor — you navigate the card's history phase by phase, seeing who did what, when, and why.

Why it matters: Customers who use Pipefy as an audit system — especially in regulated sectors like financial and healthcare — got real traceability. The question "what happened to this process?" gained a visual answer, not a log to parse.

Key decision: We launched as a modal — not integrated into the existing activity tab — to maximize validation speed. Modal placement got the feature into users' hands faster. Integration depth is a second-phase decision, not a day-1 constraint.

02 — Process Flow The start of a control plan view

The problem: Process admins who manage complex pipes — dozens of phases, hundreds of automations, multiple integrations — had no way to see the whole thing. Every configuration lived in a separate menu. Understanding the impact of a change was intuitive or required external documentation.

What we built: An interactive canvas where each phase is a node, connections between phases are edges, and automations and integrations appear in the exact context where they act. Three view modes: Flow (process as a graph), Matrix (swimlanes for side-by-side comparison), and Layers (automation logic isolated). The canvas also surfaces process mining data — real frequency of each path cards take — and AI-generated summaries per phase.

Key decision: Keeping data transformation strictly separated from rendering. On a canvas, the temptation is to mix everything. That separation made the code testable, the feature extensible, and allowed us to cover critical paths with unit tests from day one.

03 — Workflow Visualization How processes relate to each other

The problem: Large companies run multiple connected pipes — a procurement process connected to financial approval connected to contracts. There was no way to see those connections. Each pipe was an island.

What we built: A relationship graph showing all processes connected to a given pipe — connections by field references (when a card in one pipe references another) and by automation (when an automation in one pipe creates or moves items in another). Circular relationships are detected and represented correctly.

Why it matters: Operations managers gained a systemic view that didn't exist in the product before. It's the first step toward understanding the impact of a change at multi-process scale.

What Shifted

Speed of learning, not just speed of shipping

Three high-complexity features in less than 3 months, in a large-scale codebase with dozens of engineers, following the team's standards throughout — that's not achievable at traditional pace, regardless of skill level. The pod model changed the math.

But the more important shift isn't speed of shipping — it's speed of learning. In a 10-day cycle, you find out quickly whether the hypothesis holds. You don't invest months to discover you were wrong. And when it holds, the investment in a full dev pipeline feels earned.

The pod doesn't replace the traditional pipeline. It decides when that investment is worth making.

For teams thinking about how product engineers will operate with AI: this isn't about replacing design or development. It's about giving one person the leverage to validate a hypothesis end-to-end — with real quality standards, in real production infrastructure — before asking a full team to commit.

The Pod: Shipping at the Speed of a Hypothesis