Built the pin feature Pinterest acquired.
Full-stack builder on the consumer product Pinterest acquired, where the builder DNA started.
01 · The problem
What Icebergs actually needed.
Saving things you find online was broken. Bookmarks rotted into graveyards, screenshots scattered across the camera roll, and existing tools treated a saved item as a flat link instead of a piece of a collection. Icebergs set out to be a visual workspace for creative professionals: capture anything from anywhere on the web and organize it into curated boards. A small Barcelona startup had to ship a product polished enough to compete with much larger players for the behavior Pinterest was scaling globally, on a fraction of the runway. Everything (the interface, the database underneath it, the API connecting them) had to be built from nothing.
02 · Context and insight
The reframe that set the direction.
This early engineering role is the origin of the builder DNA that runs through everything since. Years before leading product at Klarna, Enso, or Pass, I wrote the UI, modeled the data, and exposed the API, owning the full vertical slice of a consumer product rather than a single layer. That vantage point made the most consequential contribution possible: I built, from idea to conception, the 'pin' feature, the mechanic for capturing a piece of content and saving it into a collection. That same capture-and-collect primitive was later introduced to Pinterest, the company that acquired Icebergs.
03, The approach
The decisions that mattered.
Own the full vertical slice, not a layer
Instead of specializing in frontend or backend, I built across the whole stack: the platform UI, the database, and the API tying them together. The tradeoff was depth of specialization for breadth of ownership. At a startup this size, one person who understands how a UI interaction maps to a data write and an API call ships coherent features faster than three coordinating across boundaries. That's what made designing the pin feature end to end feasible at all.
Design the 'pin' as a primitive, not a button
The capture interaction wasn't a single screen. It was a primitive the rest of the product was built on: how a saved item is represented, where it lives, how it's pulled back into a board. Building it from idea to conception meant making the data-model decisions and the interaction decisions in the same head, so a single click was backed by a structure that could scale into collections.
Keep the API as the contract that holds it together
With one person spanning UI and data, the API became the discipline that kept the system honest: a clean contract between what the interface needed and what the database could provide. That separation let the product evolve without the front and back ends drifting apart. It's a habit that carried directly into how I later specced systems as a product leader.
04 · How it's built
Close to the stack, not above it.
Hands-on engineering, not direction. I wrote the platform UI, modeled and built the database, and designed and implemented the API: the full stack of a consumer web product. The senior tell is the scope of ownership. Building the 'pin' feature from idea to conception required holding the user-facing interaction and the underlying data model in one design, which is precisely why it worked well enough for Pinterest to adopt after the acquisition.
The clearest signal of impact is the acquisition itself. Pinterest bought Icebergs, and the pin mechanic I built from idea to conception was later introduced to Pinterest's own product. A small Barcelona team built something a category leader wanted, and the core capture-and-collect interaction found its way into one of the most-used consumer products in the world.
What I’d carry forward
This role taught me that product leverage lives at the seam between interaction and data model, and that the people who can hold both at once ship the features that matter. It was the engineering foundation, not the product-leadership work that came later. But the instinct it built (own the full slice, design the primitive not the screen, treat the API as the contract) is the same one I bring to AI and web3 consumer products today.