Today’s Engineering & Product Leadership: 5 Lessons From Build to Succeed

Here at Very Good Ventures (VGV), we created our Flutter-focused podcast, Build to Succeed, to spotlight game-changing tech and product leaders, and to explore a question at the heart of modern product and engineering teams: What does it actually take to build the right thing, the right way, and ensure it succeeds over time?

‍

As a Flutter development agency, VGV works closely with global application development teams that are building digital products at scale in the real world.
‍

The podcast was also created because so much of today’s conversation about technology focuses on launches, hype cycles, or tools. But the real magic—and the real challenge—lives in the middle, the years between first release and long-term success. That’s where teams scale, systems break, incentives shape outcomes, and culture determines whether products thrive or slowly decay.
‍

Hosted by VGV Founder & CEO David DeRemer, the show features leaders who have built and run high-impact products at a global scale—people who live closer to the work than the headlines. They’ve shared candid stories from Nubank, Wendy’s, Etsy, Headspace, PGA of America, BMW, Google, and many others. These aren’t abstract theories. They’re playbooks earned through trial and error, breakthroughs, and years of hands-on experience.
‍

Throughout the season, these conversations revealed clear themes about how modern teams actually build in Flutter, and what they've learned as they ship, learn, and grow. In this article, we synthesize those learnings into the top engineering and product leadership trends shaping the next era of software and mobile app development.

1. Scaling Technology & Teams

Almost every guest on Build to Succeed was dealing with the challenges of scaling a product. But “scale” meant very different things depending on where they sat in their organization. These stories provide a rare look at how companies that build Flutter apps and global application development teams scale architecture, culture, and software responsibly.
‍

Nubank’s approach has become something many Flutter agencies and mobile development teams reference as an example of Flutter architecture and modern app building best practice. Thiago Ghisi, former Director of Engineering at Nubank, described a world of extreme scale: over 100 million customers, daily global releases, and a mobile experience with more than a thousand screens. You might expect the story to be about a heroic architecture diagram, but the real unlock was organizational. Teams owned experiences end-to-end, and “glue engineers” connected dots across boundaries. Canonical platforms and patterns meant thousands of developers could move quickly without colliding.
‍

Brian Abston, Senior Director of Digital Technology at The Wendy’s Company, brought scale into the physical world. 6,000 restaurants (“6,000 little data centers,” as he put it) each needing to stay in lockstep with the mobile app, marketing campaigns, and in-store operations. Their old native setup simply couldn’t keep up with the pace of promotions, menu changes, and loyalty features. “Building a functioning app is easy. Getting it production-ready is hard. Scaling it for 40 million users is another thing entirely,” he reflected. 
‍

Flutter wasn’t just a new UI layer; it was the bridge that helped marketing, operations, and engineering trust each other. Delivery speed doubled, and instead of the app being a bottleneck, it became a growth engine—an outcome many Flutter agencies and companies that build Flutter apps strive to achieve.
‍

Landon Robinson, Staff Engineer at Etsy, zoomed in on a different kind of scaling—the complexity of a two-sided marketplace. The seller app team was small, but their impact needed to be enormous. Etsy’s answer was permeability—or the “away team” model—where engineers from across the company were temporarily embedded into the team, which worked because the platform itself was approachable. Flutter allowed newcomers to contribute without months of ramp-up. Gradually, identities shifted from “iOS engineer” or “Android engineer” to something more important—“Etsy engineer”.
‍

And then there was Chris Synan, VP of Engineering at Keller Williams. When Chris Synan arrived, the organization’s app had a crash rate north of 20%, a sprawling React Native codebase, and releases happening once a quarter. The obvious answer might have been to rewrite the app, but that alone wouldn’t have fixed anything. 
‍

The real transformation started when the team adopted Flutter—paired with Very Good Start, a modern CI/CD pipeline, thousands of automated tests, and a cultural reset around ownership and transparency. Leadership supported a “go slower to go fast” approach, giving the team permission to stabilize, test, and rebuild trust in the release process before speeding anything up. The shift was dramatic. After years of slow, painful releases, Keller Williams went from quarterly deploys to weekly ones—so fast, in fact, that the business eventually asked the Flutter engineering team to slow down.
‍

Across all of these stories, the pattern that’s hard to ignore is that teams don’t just scale by hiring more people; they scale when they remove friction in their code, their process, and their incentives. This principle underpins much of modern Flutter development and explains why organizations increasingly seek a trusted Flutter app development agency.
‍

2. The Future of Development: AI, LLMs, Low-Code & Cross-Platform
‍

If 2018–2022 was about proving that cross-platform frameworks like Flutter could handle serious workloads, 2023–2025 has been about something even bigger— rethinking how software gets written in the first place.
‍

Across conversations with folks, one idea resurfaced again and again: AI is dramatically changing how we build software. But it’s nowhere near ready to decide what we should build.
‍

As organizations rethink what it means to deliver modern digital experiences, one truth is becoming unavoidable—the future of development won’t be defined by a single technology, but by how AI, low-code tools, and cross-platform frameworks work together.
‍

In our conversation with Dan Hou, Founder and Partner at Eskridge, he emphasized that AI is no longer a novelty—it’s a foundational shift. Companies are already using AI to streamline internal workflows, automate decision cycles, and unlock new levels of personalization inside their digital products. But the real opportunity isn’t just in creating efficiency; it’s in reimagining how products are built.
‍

Dan cautions that businesses often get stuck before they start, overthinking governance or trying to design the “perfect” AI plan. Instead, he argues for a pragmatic approach: start small, experiment quickly, and scale what works. Organizations that wait risk falling behind competitors who are already using AI to accelerate innovation.
‍

And while many businesses assume AI will replace traditional interfaces with chat-driven experiences, Dan challenges that assumption. Conversational UX may play a role, but it won’t replace thoughtful interface design. As he noted: “If you have to take a course to learn how to use your product, you’ve done something horribly wrong.”
‍

Instead, the most powerful experiences will combine AI-driven intelligence with intuitive UI, using tools like Flutter to deliver consistent, performant interfaces across devices—mobile, web, desktop, and emerging form factors. Multimodal AI (voice, vision, sensor data, etc.) will only accelerate this shift, enabling products to respond to context in ways that feel more natural than ever.
‍

This is where cross-platform frameworks and low-code accelerators become critical. AI dramatically increases the volume and velocity of code generation—but organizations still need a unified architecture, shared patterns, and a consistent delivery pipeline to make that code meaningful. While Flutter provides that foundation, AI multiplies it.
‍

Andrew Brogdon, Staff Developer Relations Engineer at Google, took the idea even further. If AI is going to generate more of our code, he argued, then languages like Dart need to optimize less for typing and more for reading. In that worldview, the future developer spends more time reviewing and steering than authoring from scratch. The job shifts from “I wrote this” to “I ensured this is correct, clear, and aligned with our intent” by using tools like Flutter, supported by strong architecture and thoughtful Flutter best practices, becomes even more critical.
‍

What emerges is a new development stack—human insight to set direction, AI to explore the space, cross-platform frameworks to deliver value everywhere, and disciplined systems to ensure quality.
‍

The tools are changing quickly. The need for taste, judgment, and empathy isn’t.

‍

3. Leadership, Culture & High-Performing Teams
‍

Beneath all the technical conversations this season, a consistent theme emerged— real leadership. Not the flashy kind that lives in slide decks, but the everyday decisions that determine whether teams feel supported, focused, and empowered or burnt out and lost.
‍

Michael Harker, former Vice President of Product Management at Ritchie Bros., highlighted adaptability as a leadership trait. Plans, he argued, are fine until real users interact with your system. Then the real work begins. For him, the best leaders are those who can acknowledge when a strategy is no longer working, without panic or ego, and help the team pivot responsibly.
‍

Pierre Benz, Engineering Manager at Headspace, brought a deeply human dimension to technical transformation–one that many Flutter development agencies would recognize immediately. His team inherited three separate apps and codebases after a merger—each with its own priorities, bugs, and release cycles. Consolidating to Flutter wasn’t just a technical decision; it was a cultural and emotional reset for the entire mobile app development team.
‍

Native engineers worried about their identity and expertise. Product managers feared losing momentum during the migration. Designers wrestled with preserving Headspace’s iconic calm while integrating new services and experiences.
‍

Pierre didn’t gloss over any of this. Instead, he treated the migration as a shared journey. Dedicated time for his engineers to learn Flutter was built into the workday, not squeezed in at night. Admitting “I don’t know Flutter yet” was normalized, not penalized. Failures were surfaced and used as teaching moments. Transparency wasn’t a slogan; it was a practice.
‍

In that light, leadership stops being about “driving change” and becomes more about creating conditions where his Flutter development team knows it’s safe to learn, to ask questions, to push back on unrealistic timelines, and to care about craft—even when deadlines loom.
‍

Again and again, our guests returned to the conclusion that great Flutter engineering outcomes aren’t the result of heroics, but the result of stable, healthy, well-led teams who can sustain excellence over time—exactly the environment needed to build custom applications that last.
‍

4. Building Products the Right Way: Architecture, Process & Discipline
‍

Some products succeed almost by accident because of a motivated app building team, a forgiving market, or a lucky sequence of decisions. But the stories that stood out this season were the ones where success was deliberate, and teams invested early in Flutter architecture, disciplined process, and clarity of ownership.
‍

The work done by our very own Head of Engineering, Jorge Coca, at BMW made this particularly vivid. Instead of letting each region, platform, or team spin up its own approach, he pushed toward a unified ecosystem supported by Flutter best practices and engineering. Not for the sake of elegance, but because every additional platform, stack, or deployment path adds cognitive load. Simpler systems make it easier for people to reason about change, catch bugs, and extend functionality without introducing chaos.
‍

Michael Gyarmathy, Staff Software Engineer at the PGA of America, followed a similar path. Golf operations depended on a patchwork of tools like paper forms, legacy systems, and scattered web portals. By consolidating into a single, cross-platform ecosystem built with Flutter, the team wasn’t just modernizing—they were making the organization legible to itself. In a world where every minute counts on tournament days, fewer moving parts means fewer surprises.
‍

Headspace provides perhaps the clearest example. After the merger with Ginger, the company found itself with three apps serving overlapping, sometimes conflicting experiences. Different tech stacks meant different levels of polish, stability, and performance—issues familiar to many companies that build flutter apps before consolidation. Pierre explained it simply: “The ecology of devices is why we chose Flutter. People use multiple devices interchangeably. We can get an app out that can cover all those devices”.

‍

The decision to move everything to Flutter wasn’t about ideology or trend-chasing. It was a recognition that mental health support can’t depend on which codebase a feature happens to live in. One platform meant one source of truth for bugs, one set of patterns for accessibility, and one path for improvements to reach everyone, something that building with Flutter enables. 

‍

You can see similar thinking in Andrew Tunall, President of Embrace, with his work on observability. Reliability wasn’t treated as a “backend concern”, but as an intimate part of user experience. If a meditation fails to load, if a payment doesn’t go through, if a seller can’t complete a listing, that’s not a minor glitch; it’s a broken promise. The architecture—how services are composed, how they report health, and how they fail—directly shapes that experience. 
‍

What unites these leaders is an almost stubborn commitment to clarity. Clear boundaries between services, clear ownership of domains, and clear decision frameworks for when to invest in infrastructure versus features. They resist cleverness when it obscures understanding–an approach aligned with Flutter best practices taught by the best Flutter developers in the ecosystem, VGV. They choose patterns that make sense not just to their current team, but to the next one.
‍

Building products the right way isn’t a purity contest. It’s an ongoing practice of making trade-offs explicit, documenting why choices were made, and being willing to revisit them as the world changes.

‍

5. Community, Collaboration & Continuous Reinvention

‍

The final trend isn’t about code at all. It’s about people gathering around code—and what that enables for the broader Flutter experience.

‍

When Martin Remmelgas, CEO of Codemagic, talked about the company’s early days, he didn’t start with feature lists. He started a meetup of Flutter engineers and with hallway conversations where he answered questions for free. This same grassroots energy fuels the Flutter blog, Flutter news, and community-driven Flutter development today. Codemagic didn’t grow because it shouted the loudest; it grew because it listened the longest.
‍

Frank “Puf” van Puffelen—ex-Googler, longtime Firebase advocate, and one of the most recognizable names in the developer community—has done something similar for Firebase. His Stack Overflow answers, talks, and explanations became a kind of shared language for the community. Many of today’s AI tools were trained, in part, on that work—but his impact wasn’t just informational, it was emotional. He made people feel that their confusion was valid, that their questions were welcome, and that learning in public was something to be proud of. “If there’s one thread through everything I’ve done, it’s this: I want more people to build more apps. Every new builder we empower expands what’s possible in tech,” he said. He made people feel welcome to build custom apps, to ask questions, and to learn in public.
‍

Andrew Brogdon’s DevRel work is, at its core, about creating on-ramps. His career is a reminder that one well-crafted tutorial, one talk, or one video can change the trajectory of thousands of potential Flutter engineers, who in turn go on to build things he’ll never see.
‍

Across all these voices, one thing becomes obvious: ecosystems win, not just products.
‍

A strong community helps tools survive hype cycles. It catches you when documentation lags. It creates informal mentorship loops. It keeps standards from decaying. It pushes back on bad ideas and amplifies Flutter best practices.
‍

And at the individual level, a personal culture of reinvention is becoming non-negotiable. The Flutter frameworks we use today will evolve. The AI tools we lean on now will look primitive soon enough. The organization's charts that we navigate will be redrawn.
‍

The engineers, designers, and leaders who will thrive in that reality are the ones who treat learning as a lifestyle, not a phase. They try things they’re not yet good at, choose communities where they can both give and receive help, and remain skeptical of hype, but open to possibilities. Those are the teams thatruly built to succeed.

‍