Over the last few quarters, we’ve been steadily evolving ConfigBee.

We’ve expanded our SDK ecosystem with Flutter, introduced Gradual Rollouts, refreshed our SDKs, redesigned our pricing, introduced Deployment Units, published a new Fair Usage Policy, expanded our documentation, and completely rethought how we position ConfigBee.

Rather than announcing each of these changes individually, we wanted to step back and share the bigger picture.

Along the way, we’ve spent a lot of time talking with existing customers, engineering leaders, startups, industry experts, and new design partners evaluating ConfigBee.

Those conversations shaped nearly every decision we’ve made.

One thing became increasingly clear.

Modern software teams aren’t looking for another feature flag service.

• They’re looking for a reliable way to control software after deployment.
• They want to release safely, respond to production issues immediately, experiment confidently, personalize experiences, and give engineering, product, operations, and customer-facing teams the ability to control application behavior without shipping a new version of their application.

That realization has changed how we think about ConfigBee.

Today, ConfigBee is evolving beyond feature flags into a Runtime Control Platform and Release Management Platform.

Our philosophy.

> Build once. Control everything.

Expanding the ConfigBee Ecosystem with Flutter

One of the biggest milestones over the last few quarters has been the release of our Flutter SDK.

Flutter has become one of the most widely adopted frameworks for building cross-platform applications, and supporting it has been one of our most requested capabilities.

Today, our Flutter SDK is stable and production-ready.

Teams can now use ConfigBee’s Feature Flags, Dynamic Configurations, Targeting, and Runtime Control capabilities in Flutter based applications across Android, iOS, web, and desktop platforms.

For us, this is much more than adding another SDK.

It significantly expands the ConfigBee ecosystem into the mobile space while providing the same runtime control experience developers already expect on other platforms.

Gradual Rollouts Have Arrived

Another major milestone is the introduction of Gradual Rollouts.

ConfigBee has supported Contextual Targeting for a long time.

Many teams already use it to enable features for specific users, customer accounts, organizations, or carefully selected groups.

That works well when you already know exactly who should receive a feature.

As applications grow, however, another challenge appears.

Sometimes you don’t want to manually choose users.

Instead, you want the platform to automatically and consistently select a percentage of your users, gradually increase exposure, monitor production, and safely expand the rollout over time.

That’s exactly what Gradual Rollouts are designed to do.

Start with 1%.

Observe production.

Increase to 5%.

Then 10%, 25%, 50%, and eventually everyone, only when you’re confident.

This dramatically reduces deployment risk while making progressive delivery much easier.

Targeting and Gradual Rollouts Work Together

Although they may appear similar, Targeting and Gradual Rollouts solve different problems.

Contextual Targeting answers the question:

> Who should receive this feature?

You explicitly select users, customer accounts, organizations, or other contexts.

It’s ideal for long-term feature entitlements, enterprise customers, beta programs, customer-specific configurations, and personalization.

Gradual Rollouts answer a different question:

> How quickly or safely should this feature reach everyone?

Instead of manually selecting users, ConfigBee automatically chooses a stable percentage of your audience and progressively expands that percentage as your confidence grows.

One capability is about intentional audience selection.

The other is about safe release progression.

Together, they provide a much more complete runtime control model.

To support these capabilities, we’ve updated our SDKs so Gradual Rollouts work consistently across supported platforms.

Check our SDK Capability Matrix for more details.

Beyond Feature Flags

You’ll also notice that our website looks different.

That’s intentional.

Feature Flags remain one of ConfigBee’s core capabilities, but they no longer define the entire platform.

Today, ConfigBee combines:

• Feature Flags
• Dynamic Configurations
• Runtime Control
• Release Management
• Contextual Targeting
• Progressive Delivery
• Personalization

all into a single platform.

The goal isn’t simply to toggle features.

It’s to give teams complete runtime control over software behavior after deployment.

Deploy once.

Then let engineering, product, operations, support, and customer success teams decide what users experience, feature by feature, user by user, without redeployments.

Simpler Pricing That Grows with You

As ConfigBee has evolved, we also wanted our pricing to evolve.

Our objective was straightforward.

Make pricing easier to understand while removing unnecessary friction.

Every plan continues to include unlimited Feature Flags and Dynamic Configurations.

Pricing is now centered around two primary concepts.

• Monthly Active Visitors (MAVs) – measure the scale of your user base.
• Deployment Units (DUs) – measure the operational footprint of your application.

Rollout capabilities then scale naturally with each plan, from Instant Rollouts on the Free plan to increasingly advanced rollout strategies as teams grow.

Introducing Deployment Units

Deployment Units are a new concept within ConfigBee.

Their primary purpose is to represent the overall footprint of your projects within an account.

Today, they’re primarily measured by the total number of active environments across all projects.

Rather than managing separate limits for projects, environments, and other structural resources, Deployment Units provide a simpler representation of how your organization uses ConfigBee.

Alongside Monthly Active Visitors, Deployment Units also serve as the baseline for our Fair Usage Policy, giving us a transparent and scalable way to manage platform capacity without complicating pricing.

Check Glossary & Core Metric Definitions for more details.

A Fair Usage Policy Designed for Growth

One of the most important additions in this release isn’t a feature.

It’s our new Fair Usage Policy.

We introduced it with three goals.

* Keep pricing simple.

* Safeguard long-term platform stability.

* Maintain healthy unit economics as ConfigBee grows.

Instead of exposing every operational limit directly on our pricing page, we’ve significantly increased many limits that previously created unnecessary friction and moved them into the Fair Usage Policy.

For most customers, these limits should never become something you have to think about.

Just as importantly, our Fair Usage Policy is intentionally designed to be soft.

If your usage exceeds expected allocations, ConfigBee won't automatically stop serving feature flags or interrupt your production traffic.
Instead, we'll reach out, understand your workload, discuss your growth plans, and work with you to find the right solution.

Our philosophy is simple.

We’d much rather work with our customers than surprise them with hard limits.

Better Documentation for a Growing Platform

As the platform has grown, so has our documentation.

We’ve expanded our SDK documentation, rollout documentation, glossary, and platform guidance to make ConfigBee easier to learn and easier to adopt.

Whether you’re learning about Deployment Units, Monthly Active Visitors, rollout strategies, or SDK capabilities, our goal is to provide clear explanations that help teams make the most of the platform.

Continuing to Support Startups

We’re still a startup ourselves, and we know how challenging those early stages can be.

That’s why we’re continuing our Verified Startup Program.

Eligible startups receive access to our Starter plan at no cost in exchange for collaboration and feedback, helping both of us grow together.

We’re also continuing to support eligible Startup India (DPIIT) recognized startups with additional benefits.

Supporting founders and engineering teams remains an important part of our mission.

Looking Ahead

This represents the biggest evolution of ConfigBee since we started building the platform.

It’s not defined by a single feature.

It’s the result of several quarters of listening, learning, and building.

To everyone who has trusted ConfigBee, shared feedback, challenged our thinking, or is evaluating us today—thank you.

Your ideas continue to shape what we build next.

We’re excited about the road ahead, and we’re just getting started.

Build once. Control everything.

Today marks an exciting milestone for ConfigBee as we roll out our new and enhanced targeting capabilities. After listening to customer feedback and analyzing our legacy pinpoint targeting system, we’re proud to introduce a more intuitive, flexible, and powerful approach to managing targeted feature flags and dynamic configurations.

In this post, we’ll walk you through the evolution from our legacy targeting to the new Contexts and Target Lists model, explain the benefits for both technical and non-technical teams, and share our migration strategy for existing customers.

---

A Look Back: Legacy Pinpoint Targeting

Our legacy pinpoint targeting system served as a robust solution for customizing feature flags and configurations based on specific targets i,e users, accounts, regions, and groups. It enabled you to auto-populate data for each group and allowed non-technical users to make basic customizations. However, several challenges became apparent over time:

• Developer Dependency: The legacy system required significant developer involvement throughout the process, making even simple customizations more complex.
• Limited Reusability: Targets could not be reused between users, which led to inefficiencies when managing similar configuration needs across multiple groups.
• Beta Testing Limitations: While beta testing and early access setups were possible, they often required extra effort to implement and manage.
• Centralized Control: All targeting was managed solely through the accounts page, restricting flexibility and ease of use for teams across different functions.

These limitations prompted us to reimagine our approach to targeting—focusing on delivering a solution that empowers both engineering and go-to-market (GTM) teams while simplifying workflows.

---

Introducing the New Targeting: Contexts and Target Lists

Our new targeting system is built around Contexts and Target Lists, available at the project level. This fresh approach not only streamlines feature management but also provides granular control over who gets what—right when they need it.

What’s New?

1. Context Groups at the Project Level:
   • Dynamic Entity Management: Developers and engineering leads can now manage Context Group life cycles. In a typical SaaS workflow, entities such as User and Account are defined as context groups. Once configured and activated, ConfigBee automatically populates these groups with every relevant record.
   • Granular Whitelisting: You can whitelist feature flags and configuration options at the context group level. For example, an Upload Profile Picture feature can be made available at the Users level, while features like Ticketing can be targeted at the Account level.
2. Individual Personalization:
   • Tailored Experiences: Optionally, you can activate personalization at the individual record level—enabling flags and configurations to be customized for each user or account. This ensures that every end user receives an experience perfectly tuned to their needs.
3. Target Lists for Flexible Overrides:
   • Empowering All Teams: Whether you’re from a technical background or part of the GTM team, Target Lists allow you to create and manage lists based on any context group. With a simple add/remove functionality, you can override flags and configurations for a subset of users or accounts.
   • EAP and Gradual Rollouts: Target Lists are ideal for managing Early Access Programs (EAP) and gradual feature releases. They let you seamlessly control who gets access, enabling safer, more controlled rollouts.

Key Benefits

• Delegation of Control: By shifting targeting controls to the project level, our new system allows development teams to focus on building robust features while delegating the customization and rollout strategies to the GTM team. This separation of concerns makes it easier to manage and scale feature deployments and feature lifecycle management.
• Increased Flexibility and Efficiency: With Contexts and Target Lists, you’re no longer bound by rigid structures. Enjoy the freedom to create, update, and reuse targeting configurations effortlessly—saving time and reducing developer dependency.
• Improved Personalization: The ability to enable individual personalization means that each user or account can receive a bespoke experience, driving higher engagement and satisfaction.
• Streamlined Beta Testing: Our new system makes it simpler than ever to run beta tests and early access programs. Instantly adjust and control feature exposure for specific target lists without disrupting the overall system.

---

Migration Strategy: Transitioning from Legacy to Enhanced Targeting

We understand that change can be challenging, which is why we are working closely with our existing ConfigBee customers to ensure a smooth migration from legacy targeting to our new enhanced targeting capabilities. Here’s what you can expect:

1. Guided Transition: Our customer success team will provide detailed migration guides and dedicated support throughout the process. We’re committed to making this transition as seamless as possible.
2. No SDK Integration or Code-Level Changes Required: The migration to the enhanced targeting system is entirely seamless—no changes to your existing SDK integration or codebase are necessary. This means you can transition to using Contexts and Target Lists without modifying any code, ensuring zero downtime and eliminating additional development efforts.
3. Training and Documentation: Comprehensive documentation and training sessions will be available to help you understand the new concepts of Contexts and Target Lists, and how to leverage them for maximum impact.
4. Dual Run Period: During the initial phase, both legacy and new targeting systems will run concurrently, giving you time to adapt and ensure there’s no disruption to your current workflows.
5. Feedback Loop: Your feedback is invaluable. As you begin using the new system, we encourage you to share your experiences and suggestions, so we can continue refining and enhancing the platform.

---

Conclusion

The launch of our enhanced targeting capabilities represents a significant leap forward in how feature flags and dynamic configurations are managed with ConfigBee. By moving from legacy pinpoint targeting to a more flexible system of Contexts and Target Lists, we are empowering both developers and GTM teams to take control of feature rollouts like never before.

We’re excited for you to experience the benefits of this new approach and look forward to your feedback as you migrate to and explore these enhanced capabilities.

Together, we’re making feature management more agile, personalized, and efficient—ensuring that your applications always deliver the best possible experience to your users.