Kavak

Kavak came in with a sense that growth was starting to put pressure on its structure.

The initial request seemed straightforward: build a new design system, bring coherence, and ensure all designers worked from the same foundation. At that point, the focus was on Argentina and on what already existed, a website, an app, and a set of criteria that had been defined but applied unevenly.

What began as a relatively clear scope shifted quickly.

Because Kavak is not a local operation. It’s a regional organization, with teams distributed across Mexico, Argentina, and other markets, with leadership spread across countries and products evolving in parallel. As we moved forward with early conversations, something that was already happening internally became more evident: Kopi (an existing application under development) started gaining prominence. Its more tech-driven logic, deeply influenced by AI, began to challenge where Kavak’s entire product ecosystem should evolve.

With that shift in focus, the application that had previously served as a reference point stopped being the central axis. Rather than a deprecation, it was a change in priority: the center of gravity began to move toward building a new, solid foundation for the mobile application, a starting point that hadn’t existed before.

The conversation moved away from optimizing what already existed and shifted toward something more structural: how to build a foundation for the mobile app that could support Kavak’s next stage and enable it to move with real speed.

That nuance matters. Working on something that already exists follows one kind of logic. Working on something that is being built and evolving at the same time requires another.

As we dug deeper, we found multiple worlds coexisting under the same brand: the main application, Kopi (an acquisition with its own trajectory), and variations across countries. Each had developed its own way of resolving components, styles, and design decisions.

There was also an unavoidable organizational factor. Kavak was going through a moment of organizational redesign: internal changes, new leadership, shifts in vision and scope. We integrated into that context, adapting alongside them from day one. It became clear that simply executing what had been agreed at the start wouldn’t be enough, we had to read the moment, adjust as the organization evolved, and sustain the process with flexibility.

Within that context, the scope was redefined. It wasn’t the moment to intervene in full flows or push for a deep identity redesign. First, things needed to stabilize in order to build a solid foundation that would allow scaling without friction.

The work began where structural work usually begins: tokens.

Color, typography, spacing, grids, layout… It’s not the most visible part of the process, but it’s where real consistency is defined. From there, we moved into atoms (core components), and then into more complex structures, organized under the logic of Atomic Design.

There was a conscious decision not to expand the scope beyond what had been agreed. We could have proposed more ambitious changes, even more distinctive from a visual standpoint, but the need at that moment was operational: speed, coherence, efficiency. Any identity-driven gesture that wasn’t internally aligned risked becoming a parallel discussion.

Throughout the process, we became part of the team through daily check-ins that, beyond reviewing progress, helped us understand how the team was actually using what we were building. Components were tested in real flows, questions surfaced, variables were adjusted.

As time went on, a new need emerged that wasn’t part of the original agreement: engineering teams needed support to adopt the new system. The team chose to step into that process, even though it wasn’t part of the initial scope.

That decision speaks to something deeper than technical delivery, the willingness to fill the gaps that appear, to be present where it matters, even when no one explicitly asks for it.

Instead of addressing it purely from a design perspective, we proposed opening a more strategic layer: a workshop focused on how to scale a design system at an organizational level.

What it means to govern it, how to document it so knowledge doesn’t depend on a single person, how to manage change, how to measure adoption, and how to build authority around the system until it becomes part of the culture rather than an imposed layer.

The idea was to introduce a progressive logic: educate, involve, and evolve. Not to aim for full adoption from day one, but to start with one team, measure impact, gather feedback, and help them scale in a way that was healthier for the organization.

The result was a robust system, with more than 2,200 structured, documented components, designed to support both design and the handoff to development. The focus was on mobile, building a foundation that hadn’t existed before and that now enables Kavak to move with real speed in its application.

Beyond the scale, the change was tangible within the team. Conversations shifted away from inconsistencies and started to rely on a shared reference point. Speed increased, and with it, confidence. Designing for Kavak finally stopped feeling like starting from scratch.

Kavak was looking for structure and speed for its design team, and ended up with a foundation that allows them to scale their mobile application with predictability and without friction. A foundation that is already enabling movement, and that, when the time comes, can extend further.