Code we ship
for developers.

Flutter packages and web tools we use on every build. Free and open-source.

Browse packages See on GitHub

The stack

ShipFlutterNext.jsReactTailwindWordPressDesignFigmaPenpotBackendNode.jsFirebaseSupabaseAppwriteExploringTanStack Start

Lab · Open source

Packages and tools we maintain.

Flutter packages and dev tools we build on across projects. Used in our own apps; free for yours.

github · agent skill · new

flutter-app-shots

App Store and Google Play screenshots from your real Flutter screens. An agent skill plus a Dart CLI: you approve the screens, sizes and copy, it captures them with golden tests and renders framed, store-size PNGs.

View →

pub.dev · v0.x

blaq_form

Typed, composable form builder for Flutter.

View →

pub.dev family

zego_web

Web primitives for Flutter apps targeting the browser.

View →

in the works

more coming

We open-source the patterns we use across projects.

How we build packages

Five steps. Every release.

How a pattern from our own apps becomes a package you can depend on.

01Identify
Identify
Every package starts as a pattern we used twice in our own apps.
- Watch for patterns repeated across internal projects
- Validate the abstraction against real production use
- No premature generalization — ship once before extracting
- Track candidates in our internal wishlist
What you getA pattern already proven twice in production, not a guess.
02Extract
Extract
Pull the pattern into a standalone, typed, documented package.
- New repo, fresh git history, clean module boundary
- Write the README first — it force-clarifies the API
- Strip project-specific assumptions, replace with config
- Initial test suite covering the shapes we've exercised
What you getA standalone repo whose README was written before the code.
03Harden
Harden
Types, tests, docs, examples — production-grade or it doesn't ship.
- Full type coverage, strict null checks, no anys
- Unit + integration tests running in CI on every PR
- Example apps for every public entry point
- Changelog following Keep-A-Changelog conventions
What you getFull types, tests in CI and an example app for every entry point.
04Publish
Publish
Ship to pub.dev / npm / GitHub with semver, tags, and release notes.
- Semver — no breaking changes without a major bump
- Tagged GitHub release + changelog entry per version
- Migration guide when breaking changes are unavoidable
- Announce in our dev feed with usage examples
What you getA semver release with a changelog, and a migration guide when it breaks.
05Maintain
Maintain
If you depend on our package, we respond — even to free-tier users.
- Issues triaged within one business day
- PRs reviewed within a week, with honest feedback
- Breaking-change deprecations announced a version ahead
- Long-term support on major versions we actively use
What you getIssues triaged within one business day, even on the free tier.

Say hello

Code we shipfor developers.

Packages and tools we maintain.

Five steps. Every release.

Identify

Code we ship
for developers.