Earlier quoted context omitted.
There's room for more than one player in the market here, it's a super important sort of tool where the open source versions are all pretty mediocre. OSS solutions tend to be statically configured, which non-engineers don't tend to have access or ability to configure. That's not to say you couldn't OSS something here, but it'd be a real effort to host.
I'd also add that what we're interested in is not just feature flags, but the use of feature flags for A/B testing - which translates to a few key differences in how you build and optimize the product. 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 emphasi…
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?