What we build with it
Dart is what our Flutter work is actually written in, so most of our engineering standards live at this level rather than at the framework level: how state is modelled, how errors are represented, how async boundaries are drawn.
Sound null safety is the feature that changed the most for us in practice. A whole class of production crash — the null dereference that only happens on a slow network or an empty account — stops being possible to write. Sealed classes and pattern matching cover the rest: results that carry either a value or a failure, exhaustively handled, instead of exceptions thrown across layers.
Where we have shipped it
Every app in our portfolio, plus both of our published Flutter packages. Our number_editing_controller package is a good example of Dart-level work rather than UI work — locale-aware number formatting with runtime-mutable options, where the hard part is the model, not the widget.
When we recommend it
Dart is not usually a standalone decision — you choose Flutter and Dart comes with it. Where it does become a decision is on the server: Dart compiles to native binaries and can back a Flutter client with shared model code.
We generally do not recommend that. For backend work we reach for Go, Python or Rust, where the library ecosystem and the operational story are far better established. Shared models are a smaller win than they look, and a Dart backend narrows the pool of engineers who can maintain it.
