Two Weeks to Two Days

Two Weeks to Two Days

August 24, 2026

Six months ago our most-used package, facebook_app_events, was pulling around 20,000 downloads a week. This month it peaked above 50,000 downloads per week.

We did not run a campaign. We did not ship a headline feature. We changed how fast we answer, and adoption followed.

It started as a library we needed for ourselves

In October 2019 a client needed Meta app event tracking in a Flutter app. Nothing on pub.dev did the job properly, so we wrote our own wrapper around the native Meta SDKs and published it the same month. Version 0.0.1 was internal plumbing that happened to be public.

Other teams found it. Then more. It became the most used Meta App Events plugin in the Dart ecosystem: as of today, over 180,000 downloads per month and used in more than 400 open source projects on Github.

For six years we maintained it by hand. Every Meta SDK release, every Flutter breaking change, every issue, read and reproduced by a developer on our team.

The gratitude from the community was an honor, and it still is. A message from a developer in another timezone whose analytics finally works is a better proof of competence than anything we could put in a pitch deck. Plenty of people gave back: contributors sent fixes, reproductions and platform-specific knowledge we did not have. The plugin is better than what we would have built alone.

It was also a real workload, and every hour of it competed with a client project.

The bottleneck was never writing code

facebook_app_events sits between a developer's Dart code and two native SDKs that Meta changes on its own schedule.

When someone files an issue, the report is usually one of three things: a real bug in our plugin, a change on Meta's side, or a misunderstanding of what the SDK does.

Telling those apart used to take days. A developer had to reproduce the report, open the current Meta documentation, check the native SDK behavior, then work out which layer was at fault. The resolution of an issue could stretch for a couple of weeks. Not because the fix was hard. Because the diagnosis was slow.

That is a structural failure, not a personal one. Tidelift's 2023 maintainer survey found 58% of open source maintainers had quit or considered quitting a project, with burnout the third most cited reason at 44%. Triage is where the hours go.

What we automated

Issue triage that validates the claim. Every new issue is parsed on arrival. Our triage automation pulls the relevant section of Meta's official SDK documentation and the plugin's current behavior into the thread. Before a developer reads the report, they see the claim, the documented behavior, and where the two disagree.

Notification routing. Issues reach the developer who owns the affected area, in the channel they already work in. No dashboard anyone has to remember to check.

Automated code review on every pull request. Each PR gets a machine pass before a human one: contract changes across the Dart and native boundary, missing null handling, parameter validation, behavior drift between iOS and Android.

A full codebase scan on every Meta SDK upgrade. When Meta ships a new SDK version, we scan the whole plugin against the new surface and flag what breaks. A Graph API version stops working two years after its successor ships, and Meta reserves the right to change any API on short notice for security or privacy reasons. Two years sounds generous until you are the layer in between. Our changelog shows how ordinary this is: a minimum Flutter SDK bump here, a deprecated setter there, pinned Meta SDK major versions so a breaking release cannot be silently accepted. Each one is a potential broken build in someone else's app.

A weekly security and code weakness review. It runs on a schedule, not on a good intention.

All of it runs as GitHub Actions workflows in the same repository as the code. There is no separate platform to maintain.

Response time is a tooling problem, not a talent problem

Google studied code review across its entire engineering organization. Median latency for a full review, across all change sizes: under four hours, with 70% of changes committed less than 24 hours after being sent out for initial review. That is not a difference in developer quality. It is tooling and process.

The open source community measures the same thing. CHAOSS treats Time to First Response as a core project health metric, because "the first response is often crucial as it signals to contributors that the community is active and engaging."

And the industry baseline is slower than most teams admit. In DORA's 2025 research, more than half of respondents deploy less than once a week, and when a deployment fails, 15% of teams need more than a week to recover.

Our resolution time now sits inside two days. Downloads followed, because a plugin that answers is a plugin you can build on.

Automation does not make the decision

DORA's 2025 conclusion is worth repeating: AI is an amplifier. It magnifies the strengths of high performing organizations and the dysfunctions of struggling ones. Point it at a messy process and you get into a mess faster.

So we drew a line. Automation gathers context, cross-references documentation and flags risk. A senior developer decides. Nothing merges because a machine approved it. What changed is where our developers start: they open an issue already holding the documentation, the reproduction and the diff, instead of spending a day assembling them.

The other thing that changed is the trade-off. Automation removed most of the conflict between the plugin and our client work. We serve the community better now, and client projects do not pay for it.

We run our clients' code the same way

Our open source work is not a side project with looser standards. It is the same pipeline, the same review gates, the same weekly scans we set up for client codebases. It is public, so you can check it.

Almost seven years in, the plugin is mature, and we are still committed to it. Thank you to everyone who filed an issue, sent a patch, or told us it worked.

The plugin is on pub.dev and the source is on GitHub.

If your team is losing days to triage instead of shipping, that is a fixable problem. Tell us where it hurts: hello@oddbit.id.

Sources

SolutionsProjectsOur PeopleCareerContact
Google Cloud Partner

© 2026 Oddbit

Tell Us About Your Project