Marcos Sevilla
Technical Delivery Lead at Very Good Ventures
Technical Delivery Lead en Very Good Ventures
Barcelona, Spain
Actions
I'm a Technical Delivery Lead at Very Good Ventures, a Flutter development consultancy. I build Flutter apps for large-scale companies and do open source work for popular Dart and Flutter packages such as the Very Good CLI and Dart Frog.
Soy un líder técnico en Very Good Ventures, una consultora de desarrollo Flutter. He construido aplicaciones para empresas de gran escala y mantengo proyectos open-source como Very Good CLI y Dart Frog.
Links
Area of Expertise
Topics
Crossing the Bridge: Type-Safe Flutter Plugins with Pigeon and Swift
Most Flutter developers use plugins every day and never write one, because the bridge to native
code is intimidating. Hand-written method channels are stringly-typed and untyped on both ends: you call invokeMethod('doThing'), pass the wrong argument shape, and everything compiles fine
right up until it crashes at runtime with a useless PlatformException. I hit exactly this on a project
where I had to ship plugins across multiple platforms with little method-channel experience, and
where I personally owned the Swift implementation without being a Swift developer.
Pigeon changed the calculation. By defining the interface once in Dart and generating type-safe
Swift and Dart code from it, I could focus on learning just the Swift I needed and let codegen
handle the wiring. This talk walks through building a real iOS plugin with Pigeon, scaffolded from
Very Good Ventures' very_good_flutter_plugin template, that uses Apple's Vision framework to
recognize text in images and return it as structured, type-safe data. Along the way we will see
how Pigeon fits the federated plugin structure and why type safety across the bridge is what lets
any Dart developer confidently ship native code.
I owned the iOS side of a multi-platform plugin before I really knew Swift. Pigeon is what made
that possible. Here's how to write type-safe Flutter plugins where the compiler, not a runtime
crash, catches your mistakes across the Dart-to-native bridge.
Key takeaways
• Why hand-written method channels fail at runtime, and how type safety across the bridge
prevents it.
• How to define a plugin interface once in Dart and generate type-safe Swift and Dart with
Pigeon.
• How a Dart developer can ship a real native plugin without being a Swift expert.
It's Just a While Loop: Building Agentic Apps in Flutter with the Claude API
If you write Flutter, you've probably watched the AI wave from the sidelines, assuming agents are
some exotic Python-and-cloud thing happening to other people. They aren't. This talk takes the
mystery out of agentic AI by showing what's actually inside the box, using a real, open-source
Flutter app rather than a toy. A single Claude API call returns content blocks and a stop reason,
and when that reason is tool_use, the app runs the requested tool, hands the result back, and
asks again. Wrap that in a loop and you have an agent. That's the whole trick, and the loop that
does it is about forty lines of Dart.
I'll start with a live demo: I'll ask the app to save an article and remind me to read it in two days,
and we'll watch Claude chain several local tools together to get it done. Then we'll go under the
hood and read the code that made that happen, built on the anthropic_sdk_dart package. We'll
look at the agent loop itself, how a tool is defined as a schema plus a plain Dart function, and
how a thin repository layer and a Bloc keep the whole thing testable and maintainable. I'll close
by showing how the same loop unlocks streaming, extended thinking, prompt caching, and the
Files API once the basics are in place. You'll leave knowing the Claude API is approachable from
the language and framework you already use, with the repo in hand to add your first tool this
week.
Everyone talks about AI agents like they're magic. They're not. An agent is a while loop around
the Claude API. I'll demo a real Flutter app doing it, then walk the actual code that makes it work.
Key takeaways
• Why an AI agent is just a loop around the Claude API, in about forty lines of Dart.
• How to define a tool as a schema plus a plain Dart function the loop can call.
• How a thin repository and a Bloc keep an agentic Flutter app testable as it grows.
One Dependency: A Layered Flutter Architecture With Just Provider
Open a typical Flutter project's pubspec and you will find Bloc or Riverpod, a dependency-injection container, and maybe a code generator or two, each adding API surface, a learning curve, and migration risk. Often they are redundant, and the team cannot say what each one actually buys. Every abstraction has a cost, paid in onboarding time, debugging through layers of indirection, and dependencies nobody can justify.
This talk keeps the clean, layered architecture most teams already want, data, repository,
business logic, and presentation, and strips out the framework tax. The boundaries and the
testability stay. The business-logic layer is built from APIs that already ship with Flutter: ValueNotifier for state and Provider for wiring it into the widget tree. We walk a real feature end to end, then look at how the same structure scales to a feature-first monorepo using Dart's built-in Pub Workspaces. You will leave able to start your next app with zero state-management packages, and with a sharper sense of when a dependency is actually worth its cost.
Most Flutter apps drag along a stack of state-management and dependency-injection packages
that nobody on the team can fully explain. This talk takes the opposite approach and finds the
least architecture an app actually needs, rebuilding a clean, layered, testable app with one
dependency you already know how to use: Provider.
Key takeaways
• How to build a clean, testable, layered Flutter app using only Provider and ValueNotifier.
• A framework for deciding when a state-management dependency actually earns its cost.
• When to reach for Bloc or Riverpod on purpose, and how to start your next app with zero
state packages.
You Don't Need a Package for That
Every Flutter project starts clean, then the dependencies pile up. A package for tuples, a union-type library, a state-management package wired in for a single toggle. Take freezed, which most Flutter developers know and love. A few years ago, reaching for it was obvious. Today the language has caught up. Dart 3 ships sealed classes, exhaustive switches, pattern matching, and value equality for records, which cover the union and matching features most teams actually used freezed for. freezed still earns its place when you need copyWith on complex models or JSON serialization, and that is exactly the point. The bar for adding a dependency rises every time the SDK absorbs what it used to do, so the package has to justify itself.
This talk names that reflex, then tours the features hiding in plain sight. Records and pattern
matching for returning and destructuring data, and for equality without equatable. Sealed classes and exhaustive switches for modeling loading, success, and error so the compiler flags the case you forgot. ThemeExtension for keeping design tokens in the theme instead of a scattered constants file. ValueListenableBuilder for rebuilding only the widget that changed instead of pulling in a state package. Each comes with a before and after: the package or boilerplate you ship today, and the few lines of built-in Dart or Flutter that replace it. You will leave able to open your own pubspec, find a dependency that no longer earns its place, and delete it tonight.
The bar for adding a Flutter dependency rises every time the SDK absorbs what it used to do. A
fast, example-driven tour of the Dart and Flutter features now built in, and how to tell which
packages in your pubspec still earn their place.
Key takeaways
• How to tell when a beloved package like freezed is doing work the language now does for
free, and when it still earns its keep.
• The built-in Dart and Flutter features that replace union types, tuples, scattered theme
constants, and single-toggle state.
• A concrete habit for auditing your pubspec and deciding which dependencies still justify
themselves.
Your App's BFF: Backend for Frontend in Flutter
Every mobile team knows the friction: endpoints that aren't ready, data spread across three calls that should be one, contracts that shift mid-sprint, and the constant context-switch between Flutter and whatever language the backend speaks. A Backend for Frontend layer, written in Dart Frog and deployed on the cloud, fixes it, and in the language you already ship Flutter in.
The surprise isn't that a BFF cleans up your data, it's that it decouples the two teams in both directions. On a real client app we built whole features before their endpoints existed, mocking the shape we wanted in the BFF in minutes. When the real APIs arrived, we only tweaked the BFF to call them and the app's UI never changed. The flip ran the other way too: the backend team took endpoints straight from our BFF and used it as the spec for what to build. No blocked sprints, no surprises, and the BFF became living documentation of what the app actually needed.
This talk is for Flutter developers who've never written backend Dart and don't think they need to. You'll leave seeing the handoff as something you can own, not endure. Case study:
verygood.ventures/success-stories/blade-mobile-flutter-app
Waiting on a not-ready API is the frontend's oldest nightmare. A Backend for Frontend written in
Dart hands that control back to your team. On a real production app, ours flipped the handoff
completely: the backend ended up building against the frontend's spec, not the other way
around.
Key takeaways
• How a Dart Frog BFF flips the frontend and backend handoff so the backend builds against
your spec.
• How to model the endpoint you want in the BFF first and unblock app work before the real
API exists.
• Why writing backend Dart turns the API handoff into something you own rather than endure.
Marcos Sevilla
Technical Delivery Lead at Very Good Ventures
Barcelona, Spain
Links
Actions
Please note that Sessionize is not responsible for the accuracy or validity of the data provided by speakers. If you suspect this profile to be fake or spam, please let us know.
Jump to top