Some projects stay with you long after the final handoff. Mozi was one of those projects for me, thanks to the lessons I learned ideating an app from scratch with someone who helped shape the Internet. Kind of a privilege!
For nearly two years, I had the opportunity to work closely with Ev Williams—co-founder of Blogger, Twitter, and Medium—alongside an incredibly dedicated team at Z1. We explored prototypes, defined early MVPs, and shaped the foundations of a product that aimed to rethink how we stay connected with the people who matter most.
When Mozi launched publicly in December 2024, months after our direct involvement had ended, many of the core flows, hypotheses, and early decisions we shaped were still visible. For any product team, that’s deeply rewarding.
Looking back, Mozi taught us powerful lessons about staying grounded in product fundamentals, choosing partners who let you test with confidence, and accepting that early versions hold truths you don’t always appreciate in the moment.
Here’s what it felt like to navigate that product journey from the inside.
A vision worth building
From the very first discovery conversations, Mozi’s ambition resonated with me. Ev had a clear intuition: social apps had drifted away from helping us stay close to our actual friends. We were “connected” but rarely genuinely in touch.
Mozi was meant to correct that. A private, intentional space to plan real interactions, not another place to perform or endlessly scroll. It targeted people with complex lives, crammed calendars, and high expectations for both security and experience: a product built around trust, subtlety, and human nuance. You could share your upcoming plans, see when friends were in the same city, or keep personal notes that make relationships easier—kids’ names, life updates, preferences, everything that strengthens real connection.
For us at Z1, it was a challenge that aligned naturally with our ethics and our love of clarity.
Our role: Prototyping, testing, and learning
At Z1, my role is to shape priorities, keep the puzzle pieces together, and test, validate, or discard each iteration—no matter how big or small—driving us closer to a version we feel fits the product goals.
Product designers Irene Utrilla and Lucía Guillén were essential partners throughout Mozi's process, translating our hypotheses into interfaces that felt immediate and elegant. We also had a dedicated engineering team building in native Swift, as the client preferred. One of those engineers, Martín Bueno, impressed the Mozi team so much that he later joined them.
Social products rely on network effects and psychological nuance.
Social products like Mozi rely on network effects and psychological nuance, so we explored several directions to understand which behaviors could be validated early—and which required deeper product investment.
We explored multiple directions: different flows, mechanics, and assumptions about what users would actually adopt.
We shipped:
- Interactive prototypes to explore flows and test assumptions.
- Several MVP builds, each framing variations of the core experience.
- UI refinements based on new brand directions.
- Bi-weekly iOS builds ready for internal testing.
One thing I always try to remind founders of: pivots are not failures; they’re progress. Mozi’s process embodied that completely.
The branding of a functional product
Alongside Z1, Mozi collaborated with an agency with a strong conceptual approach to the product’s branding. Working with external brand partners is something we’ve done many times at Z1, and we’re used to dealing with all types of branding directions, including those not originally designed with a digital product in mind.
This always creates an interesting challenge for our team: how to take static brand elements and translate them into a functional, scalable UI system that could support real interactions, legible patterns, and intuitive navigation.
This translation was where Irene and Lucía’s expertise became essential. They respected the creative vision of the brand but ensured that every visual expression preserved usability, accessibility, and the constraints of native development.
Bringing an already created brand to life inside a new digital product is always an act of interpretation. It’s where design evolves from a more aesthetic exercise to one that emphasizes systems, features, and clarity.
Navigating complexity (and its many plot twists)
Early-stage products evolve constantly—sometimes gradually, sometimes dramatically. With Mozi, we navigated several phases of redirection as new leaders joined, priorities shifted, and the vision solidified.
This demanded extreme adaptability from the whole team.
On my side, as product manager, it meant:
- Keeping everyone aligned
- Constantly reassessing scope
- Managing expectations across different stakeholders
- Ensuring each decision had a clear impact on the timeline and development flow
Working with high-profile founders brings an exciting pace and intense expectations. But it also reinforces one of my favorite parts of product work: the collaboration between PMs, designers, and engineers. When that trio is aligned, even the most complex requests become solvable.
Pros and cons of building your app in Native Swift vs in React Native
Choosing the right programming language and tech stack for your first version matters, and we always help our partners navigate this decision with both technical and product criteria in mind.
Mozi’s MVP was built entirely in Swift, a powerful and demanding choice that delivers outstanding performance, deep OS integration, and long-term scalability. Native development gives you maximum control, top-tier polish, and a strong foundation for complex, iOS-first products. But it also comes with higher development effort and slower iteration cycles—two important trade-offs when you’re still validating assumptions, testing behaviors, and exploring what the product truly needs to become.
In an earlier exploratory phase, React Native could have been a compelling alternative. A cross-platform framework allows teams to build for iOS and Android from a single codebase, significantly reducing time-to-market and development cost. This efficiency often translates into faster experimentation: features can be prototyped, tested, discarded, and rebuilt with less friction. For MVPs, where learning speed is more valuable than technical perfection, this can make a critical difference.
Swift is a powerful choice that delivers outstanding performance and long-term scalability but it also comes with higher development effort and slower iteration cycles.
Today, that case is even stronger. With React Native’s new architecture, the historical performance and capability gap with native has narrowed significantly. Modern RN delivers near-native performance for most product needs, and when deeper platform access is required, native modules can be integrated seamlessly. This makes React Native an increasingly robust option for teams that want both speed and technical credibility at the MVP stage.
React Native also tends to lower the barrier between design and engineering. UI changes can be shipped faster, shared components encourage consistency, and product iterations feel lighter. That agility is especially valuable when product direction is still fluid and when insights from early users continuously reshape priorities
Building in native Swift was a deliberate technical decision aligned with the product’s long-term requirements. From the outset, the founder had clear expectations around performance, system integration, and scalability, and we evaluated the stack with those constraints in mind. We fully understood those needs and adapted our architecture accordingly.
We always help our partners to choose the right tech stack for their V1 with both technical and product criteria in mind.
Our engineering team delivered consistent builds every two weeks, translating evolving designs into stable, production-grade features. Native Swift gave us direct access to iOS frameworks, fine-grained control over memory and performance, and the ability to design a codebase optimized for complex interactions, real-time behaviors, and future platform evolution. This reduced technical uncertainty around edge cases, OS-level features, and performance ceilings that can appear later when products built cross-platform begin to scale.
From an engineering perspective, starting in Swift allowed us to establish a robust foundation early: clean, modularized code, predictable performance characteristics, and a codebase ready to absorb future complexity without large rewrites. It also simplified critical areas such as debugging, profiling, accessibility, and system-level optimizations, which were essential to the quality bar Mozi aimed for.
Choosing Swift meant higher upfront engineering effort, but lower long-term technical risk. Our processes were designed to compensate for that cost: tight iteration loops, continuous integration, frequent releases, and close design-engineering collaboration to preserve speed of learning while maintaining native-level quality.
Every cycle generated actionable feedback and concrete technical insights. What we delivered was more than an MVP; it was a technically solid first version capable of supporting rapid product iteration, deeper platform features, and the transition from early experimentation to a scalable, maintainable iOS product.
MVP, where the product’s heart lives
When I finally saw Mozi launch, I felt something very specific: recognition.
Much of what reached the world resembled one of those early MVP directions we explored months before. That happens more often than people think. The “simple but true” version—the one that feels almost too obvious—is usually where the product’s heart lives. Mozi reconfirmed this for me.
As Lucía said at the time:
“The product that reached the world carries traces of the foundational thinking, user flows, and interaction models we explored from the very beginning. That’s deeply rewarding.”
And it is.
Mozi taught me why I love this work: Helping founders turn complex, ambitious ideas into clear, intentional product experiences that people actually enjoy using.
Every product journey teaches you something if you’re paying attention. Mozi taught me, once again, why I love this work: Helping founders turn complex, ambitious ideas into clear, intentional product experiences that people actually enjoy using.
If you’re navigating early-stage uncertainty and want clarity on what comes next, we’d love to help.
