If you’re ever used a feature flagging tool for a B2B SaaS product you might have noticed things feel kind of awkward. Here's why and how Bucket can help.

You should make it as easy as possible for users of a feature to give feedback to the builders of the feature, fast. Here's how we do it at Bucket.

We prioritize craftsmanship at Bucket. So, when we started building the authentication feature — the first interaction you have with the product — we wanted to make it a great first-time experience, and using Clerk was a no-brainer. Here's why.

When you search Google for Trunk-based development, this is the title of one of the first results: Isn’t "trunk based development" just a complete crock of shit? It seems there are some misconceptions to clear up.

What if your whole team could just work on the same code at the same time to avoid these merge conflicts AND there was a quick way to deactivate features that aren’t behaving without needing to deploy? This is where trunk-based development comes into play.

TLDR; Bucket is the better option for B2B companies.

We’ve added feature flags to give B2B product teams a better way to release features - from gradual rollout to customer satisfaction.

Product teams are rightly told to focus on outcome over output. But, there’s a problem with outcome-driven product development: The feedback loop is slow.

We had a positioning problem. This March, we drew a line in the sand and picked a product category. We’re Customer-Centric Feature Management.

We’ve all read the theoretical articles about using “insights” to “evaluate” and build better products. Now, there’s nothing wrong with these but they’re missing the most important part: how to actually do it in practice and in a repeatable manner that doesn’t take up your whole week.