Agustín Trossero

Foundry · Product and design lead · 2026

Reuse first. Then build.

The block registry of MoveUp Console: every block of seven sites in one place, and a path from a design to a pull request. The idea and the design are mine; an engineer on the team built it.

PRODUCT DESIGNDESIGN SYSTEMSDESIGN TO CODEINTERNAL TOOLSWORKFLOWDEVELOPER EXPERIENCE

Captured from the live tool, read only, with interactions animated over real captures. Registry figures as of September 2026.

blocks in one registry
176
sites on two engines
7
of blocks run on two or more sites
70%
blocks run on all seven
9

Overview

Foundry is the first module of MoveUp Console, an internal suite to build the components, publish the content and read the numbers across every site in the network. It is the registry of the blocks behind seven sites on two engines, and it answers one question: which blocks exist, on which site, on which engine, and where each one is in the pipeline. The idea and the design are mine, from the library to the flow that takes a design to a pull request. An engineer on the team built it in code and added what developers need to receive new blocks and updates.

Opportunities

  • One source of truth

    How might we know, for any block, where it runs and where it stands, without anyone keeping a list by hand?

  • Reuse before building

    How might we make reusing an existing block the easiest path, before anyone designs a new one?

  • A design developers can plug in

    How might we hand over a new block in a shape developers can plug into a site, with no back and forth?

  • Safe by default

    How might we let anyone ask for a deploy without anything running blindly in production?

Approach

  1. 01

    Read from the sites, not typed

    Nobody keeps the registry by hand. Foundry reads the blocks each site actually registers: UAT tells it a block exists and production tells it the block is live. The library lists every block with its live preview, data contract, engine and repo, and one dot per site: live, in UAT, draft or absent.

  2. 02

    One block, seven sites

    Reuse starts with a search. A block page shows every site the block already runs on, with its engine and stage, so a team can pick it up instead of drawing it again. Foundry lists and never merges: the same block can run on seven sites with different code, one rendering per site.

  3. 03

    The data contract comes first

    Making a block is a four step wizard: data and site, design, map and tokens, publish. It starts with the data contract, the fields the block reads from one of the shared data objects, so design and code agree on the data before anything is drawn.

  4. 04

    Design in. Block out.

    The design arrives as a zip: a preview, the HTML and CSS, the editable fields and a note. The designer sets the look, the sample content and the fields, with no PHP and no data wiring. Foundry renders it live and opens a draft pull request in the right repo, with a scaffold a developer refines before the merge.

  5. 05

    Tested on a real request

    I ran the whole flow on a real request: an editorial popup with three operators for ToffeeWeb, closable and responsive. A similar modal already lived in the ToffeeWeb theme, so I designed an editorial variant in Claude Design with ToffeeWeb's real tokens, packed it as a zip and opened the pull request from Foundry. The test also caught a failing upload of binary files, fixed the same day. The block now waits in review with its live preview.

    The draft pull request for the new block: twelve files, labelled for ToffeeWeb
    The pull request card recreates the real draft pull request, without its author.
  6. 06

    Reuse, measured

    Reuse is counted, not assumed. The 176 blocks make 458 placements across the seven sites: 229 live, 227 in UAT and 2 in draft. 123 blocks, 70% of the registry, already run on two or more sites, and 9 run on all seven.

  7. 07

    Deploys stay deliberate

    Every block moves through Draft, pull request with preview, In UAT, To deploy and Deployed, and its stage comes from the app, GitHub, UAT and production, never from someone updating a status. Deploy to production never runs anything blindly: it records who asked for which block on which site, and hands back the exact steps for the manual deploy.

Impact & Outcomes

  • One registry for seven sites: 176 blocks, each with its sites, engine and stage, read from the sites themselves.
  • Reuse made visible: 123 blocks already run on two or more sites, and nine on all seven.
  • A path from a design to a draft pull request, tested end to end on a real ToffeeWeb request.
  • Deploys that stay deliberate: every request to production is recorded, and nothing runs on its own.

Next case · Casino Template Set

Same blocks. Same data. Five identities.