Expert Portal: replacing a tool with a squad of three

Replacing the tool without the standard team

The Expert Portal had to replace Impartner in a short window. The decision to leave the tool had already been prepared: the subject was no longer convincing the organization that an in-house portal was necessary, but delivering it without recreating a heavy project organization around it. The strategic side of the decision is told in Expert portal rebuild: preparing a strategic decision through proof. This case is about the delivery mechanics that made that decision executable.

The shipped product did not have a single surface. It had a public front, the agency directory visible to merchants at experts.prestashop.com/fr/agences, and a private back office for agencies, available only with an account from experts.prestashop.com/fr/connexion. That separation matters here: the public part can be linked to directly; the agency space remains shown as wireframes.

The core team held three roles: a PM, a backend-oriented tech lead, and me on design. At that size, the classic handoff model became a risk in itself. If product wrote, design produced mockups, then development rebuilt screens while interpreting gaps, the mechanics would have consumed too much time and attention.

The team had to replace the tool, and also replace the way work was produced.

The handoff trap

Handoff works when the team can absorb translation between crafts. Here, that translation would have been the hidden cost of the project: reworking screens, explaining states, correcting spacing, arbitrating empty cases, checking multilingual content, reopening topics after integration.

This was not a goodwill problem. It was a mechanics problem. Every relay added a layer of interpretation when the team needed to reduce ambiguity.

The structuring decision was therefore to move part of design into the product itself. Figma remained useful to clarify intent, share a direction or keep a record. But code became the source of truth for the interface.

Three sharper roles

The PM was not replaced by a prompt. Her role became more demanding: make the problem, business rules, open decisions and acceptable tradeoffs explicit. The brief was not a ticket thrown over a wall, but a living object AI could help challenge because it was clear enough.

The tech lead did not only intervene at the end to review. His work started before generation: set conventions, structure instructions, clarify the boundaries between front end, backend and API, make the codebase workable. One of the clearest lessons came from an initial mistake: too many global instructions, too much architecture injected in one place, and AI mixed responsibilities. The fix was not to ask better. It was to frame better.

On the design side, the role changed in nature. Interface, density, hierarchy and state decisions were no longer only described in a mockup. They were worked on in the front end, corrected in the browser, committed, then picked up by development when API integration required it.

This redistribution did not erase the crafts. It removed part of the translation between them. Product did not become design, design did not become backend, the tech lead did not become the guardian of every visual micro-decision. Each role kept its sovereignty, but the relay happened on more executable artifacts.

From ticket to production, a marked path

The effort held because the path was repeatable. Every topic followed the same route: Jira ticket, dedicated branch, decomposition, code, review, commit and PR, merge, preproduction, production.

Decomposition was a design step in its own right. Before the first line, the feature, target files, expected states, integration points and blocking questions had to be named. That moment protected the rest of the flow: AI could produce fast because the problem had been reduced to a clear surface.

The review was not a soft read-through. It covered tests, architecture, CSS, i18n, TypeScript, design system usage, playground and commit format. Each step had a human validating the direction and a guardrail framing the action.

The playground as a place of truth

The most important lever was not a demo page. It was a workspace: a development-only section playground where each piece of the portal could be seen in its key states.

A screen is never only its ideal state. It has an empty state, loading, error, partial data, another permission, a longer language. The playground made those variations navigable without waiting for the whole backend. Design could move forward on a real experience, while backend kept its attention on data, rules and architecture.

The boundary mattered: mocks stayed in the development frame, API calls remained the responsibility of integration, and the design system served as the default constraint. The goal was not to hack faster. The goal was to produce a front end accurate enough to become a working base, not an illustration.

The method born on this effort was later formalized as Playground-driven design. This case shows the context that made it emerge; the method explains how to replicate it without copying the exact implementation.

The front-end design cycle

The front-end cycle used the same pipeline as development, but changed what coding meant. Here, coding was designing in the final medium.

First: framed intent. The work started with a prompt that set the need, the screen goal, the design system constraints and the states to cover. No blank page, no generation before ambiguity had been reduced.

Second: AI proposal. The agent produced a first screen, never empty, already constrained by existing components. That first output was not the answer. It was workable material.

Third: vibe design. Iteration happened on the real screen. Hierarchy, density, rhythm, label clarity, state balance: corrections came from the rendering, not from an abstract spec.

Fourth: arbitration and validation. Once the screen was right, it went back into the common flow: review, commit, PR, merge, preproduction, production. This was not skipping design. It was moving design iteration into a more demanding medium.

Three layers of guardrails

The system did not rely on permanent vigilance. It relied on three layers.

The first layer was written: hierarchical instructions loaded by context, with a clear separation between product vision, technical conventions and design rules. The initial mistake had been concentrating too much in one frame. The correction was splitting it.

The second was automated: conventions, type-check, lint, tests, build, hooks and CI. AI could write fast because the base mechanically rejected part of the fragile output.

The third was visual: local playground, targeted tests, specialized reviews, direct comparison with expected states. Without fast visibility, generation speed would only have accelerated late error discovery.

A simple rule also summarized front-end writing: PUiK first, custom only when the design system did not cover the need. Leaving the system had to be explicit, rare and justifiable. That constraint is what made the product maintainable after the acceleration.

What AI really changed

AI accelerated execution, but it did not carry product responsibility. It generated, restructured, proposed, corrected, documented. Human arbitration stayed in charge: what had to be visible, what had to wait, what had to stay inside the design system, what could be mocked, what had to be handed to backend.

The practice was measured. Over the rebuild window, the work represented 206 hours of active AI direction, 235 commits and 21,458 directed AI actions. Those numbers do not prove that AI does the work. They prove that a large part of execution can move if the frame is explicit enough to remain controllable.

The tools also changed along the way. Claude Code carried part of the effort, and Codex took a growing place afterward. That shift is revealing: the method did not depend on a single tool. It depended on the ability to write the rules of the game, verify the result and correct without losing direction.

What the squad delivered

V1 of the in-house portal was delivered for the June 2026 cutover. When I left, the tool was in production: the merchant-facing public directory was available online, and the private agency space went through login. The important point is therefore not only that the previous tool was replaced. It is that the new work mechanics left a more modifiable base: visible sections, identified states, versioned interface decisions, a clearer separation between front-end experience and backend integration.

In such a small team, that clarity mattered as much as speed. Product could concentrate energy on rules and arbitration. The tech lead could secure the rails and hard points. Design could move forward without waiting for every piece of data to be available, while staying inside the product.

The design-dev loop did not disappear because the crafts had merged. It became shorter because each role took sharper responsibility.

First signals after launch

The previous tool imposed a major constraint: part of the value remained invisible. The program knew activity existed, but it could not properly read views, contacts, request qualification or agency dynamics.

The new portal changed that as soon as it went live. Over the June 1 to July 31, 2026 window, the first signals became observable: 247 connected partners, including 91 new and 156 reactivated; 139 new self-service accounts; about 36 unique merchants submitting a brief, for 87 raw submissions; 70 certifications purchased; 211 active subscriptions; 417 verified stores.

These figures are not a final conclusion. They mostly say the program came out of the fog. What was previously impossible to objectify can now be tracked, compared and improved.

Perfect Match is the logical consequence of that new foundation, not a production proof to claim here. The previous directory could display profiles. The new portal can structure a merchant brief, qualify the need, use cleaner agency data and prepare a more credible matching. The point to value is therefore the capability made possible by the portal, not a Perfect Match launch status.

What the model does not prove

This case does not say that a squad of three is always enough to replace a tool. It says the opposite: the model only holds if the V1 scope is bounded, the backend layer can be isolated, the design system already covers much of the need, work instructions are treated as infrastructure, and someone truly verifies what AI produces.

Without those conditions, acceleration becomes debt.

The lasting lesson is this: designing in code is not an anti-Figma posture, nor fascination with AI. It is a way to remove a translation when that translation costs more than what it protects.