What you don't get out of those libraries alone is a couple things. One is a metrics pipeline if you want to actually A/B test and gather metrics on the success of different features. That's a hard problem because A/B metrics collection pipelines are something pretty much something everybody reinvents from scratch right now to fit their combination of language/logging tool/cloud host/data warehouse/BI tools/whatever.
The other big one is the managed configuration deployment - a UI that you can toggle features on and translate those to appropriately flipped toggles in all of your clients (mobile, web backend, web frontend, whatever). That's a pretty big task to do and requires a hosted service one way or another. Flipper (below) looks like it integrates into a rails service and so has a UI, which is kinda neat (first time I've noticed an OSS solution that does that part - looks like theres a number of options that do this now), but you'd still need to reinvent tooling for mobile apps and such with it.
[0]: https://github.com/jnunemaker/flipper [1]: https://github.com/disqus/gutter
A few things:
1. More sophisticated targeting; i.e., different types of objects, combinations of attributes, and groups.
2. Airship's pricing model is aligned with customers' incentive to grow. Our architecture emphasizes local computation, so performance and cost scale very well (better than things like MAUs) - savings that we pass onto customers.
3. Airship will integrate with existing analytics tools (like Segment) so you have A/B testing capabilities without doing set up work. You can even set up an A/B test retroactively (after the feature has shipped), because Airship can annotate the events & metrics you already track.
4. Airship focuses on non-engineering teams as well (PM, Data, Growth), and making the dashboard intuitive for those use cases.
The pricing partially based on API calls feels somewhat vague though, it's tough to have any idea what an API call is in airship, especially given the abstraction level of the client where you explicitly remove the API from the sight of the developer. .1ms timings suggests it's not per flag, but then I see "Every time you check whether a User or an object should clear a particular gate". With that context 10,000 (or 75,000) seems very low - with 30 feature flags on a page you'd only be able to load 300 pages total across all users. It doesn't feel like I can judge how the API limits translate to real world usage, even though I do see the notes on the pricing page.
One thing I might recommend for the future as a killer feature is considering tooling around application performance between two cohorts. I've definitely seen cases where toggling a feature flag changes performance from 100ms to 800ms and nobody bats an eye because most small (and probably most large) organizations have crummy performance monitoring/tooling (PMs would probably love this too for projects with explicit performance goals).
What's the expected time in Airship for clients to pick up new configurations currently?