Use Statsig just like the people who built it

We’ve been using Statsig for the past four months across different surfaces:, our main landing page,, our main web interface for using Statsig as a tool, and in some internal tools we’ve built for ourselves. Coming from Facebook, it was natural for us to use Feature Gates to “gate off” features under development, Dynamic Configs to decouple configurations from front-end code, and Experiments+ to start optimizing our conversion funnel. We use all of these and more every day. But where did we get started? …

Bringing conditional evaluation to a server near you

Background: This post assumes some prior knowledge of Statsig Feature Gates (Feature flags). You can read more in our article: What are Feature Flags?

To evaluate Feature Gates on your servers or in your clients, Statsig provides SDKs in a number of different languages. Let’s explore how they work.

Statsig SDKs target two different types of environments:

  1. Single-user/client-side environments (check Feature Gate values and experiments for the current user)
  2. Multi-user/server-side environments (check Feature Gate values and experiments for the user associated with the current request)

All SDKs expose a similar API:

  • initialize() — setup the SDK
  • checkGate() — gets the…

Rules, Conditions, and You!

Note: this posts assumes some prior knowledge of feature flags and how they can help with modern software development. If you’re already sold, and just want to learn a bit more about how they work, read on! At Statsig, we call them “Feature Gates” — they act as a gatekeeper to new features. I’ll refer to them as such for the remainder of this post.


At a high level, feature gate evaluation goes like this: a developer wants to know if a user is eligible for a certain feature, so they check that user against the Feature Gate they created…

Develop in Kotlin, Test using mockk, and Publish with JitPack

1. Develop in Kotlin

Anyone doing Android development in 2021 and beyond should strongly consider using Kotlin. Here are a few of the key features and reasons we chose to use Kotlin:

  • Safety: primarily null safety, which Kotlin’s type system is designed around
  • Async Programming: Kotlin Coroutines and support for async/await make asynchronous programming simpler, removing scattered callbacks and boilerplate AsyncTasks
  • Style: Kotlin is nicer to read and write. Data classes, singleton objects, etc. are much less verbose
  • Java Interop: Java programs can call into Kotlin libraries, and vice versa. Without this, building a Kotlin SDK would be a nonstarter

Still not sure about…

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store