For a small SaaS choosing feature flags, the self-hosted versus managed decision is safe only when the team can tell a bad tenant-cohort treatment from bad telemetry and can stop exposure without waiting for a control plane to recover.
Short answer: for a small SaaS that needs enable/disable checks and gradual rollout, choose managed basic flags when reducing operational surface matters most; choose a dedicated self-hosted or enterprise platform when audit history, advanced targeting, or stronger governance is part of the release requirement.
Don't crown a winner from a pricing-page screenshot. The useful comparison is total operational cost plus the quality of the decision signal: who runs the service, how quickly clients observe a change, what evidence survives after a change, and what page fires when a cohort starts failing. Current plan prices can settle a tie, but they can't repair an experiment whose exposure data is missing.
How should a small SaaS compare feature flags, self-hosted tools, and managed pricing?
Start with the rollback promise, then work backward. Write down the maximum tolerable time between changing a flag and every affected client observing it. A client that polls cannot offer instant propagation, so a UX-sensitive release needs a polling interval that fits the rollback objective, plus a server-side kill path where the risk warrants one. This is a mechanism, not a dashboard color.
Next, define the cohort unit. For a developer-tool experiment, tenant_id is usually more defensible than user or request because the product decision is about organizations and a single tenant should not see contradictory treatments. The exact choice depends on the product's tenancy model; I'm not sure a user-level split is wrong for every tool, but it must be justified before rollout, not during the postmortem.
Then specify three separate signals: exposure, outcome, and guardrail. Exposure says which tenant actually received which value. Outcome represents the experiment's intended result. A guardrail represents harm, such as an elevated error ratio. Without exposure, a clean aggregate chart can hide that almost nobody entered the treatment; without a guardrail, a positive engagement result can conceal operational damage. Keep metric names stable and use labels for dimensions rather than encoding tenant identifiers into metric names. Prometheus's naming guidance is a good baseline for that discipline.
One question decides more than the feature matrix: what page fired? If the answer is “someone noticed a dashboard,” the release procedure has an observation, not a response path.
The failure mode is noisy evidence, not a missing toggle
Imagine a gradual rollout to 10% of eligible tenants. The aggregate request error ratio moves from its baseline, but the exposure event has no flag revision, one client population refreshes by polling, and the graph combines control and treatment. There is no defensible causal read. Increasing the rollout to collect more data would amplify risk; turning it off would be prudent, but the postmortem still could not establish whether the treatment, cohort assignment, or telemetry path was responsible.
That ambiguity is the incident.
The minimum event record should let the team join an exposure to the resulting behavior without leaking sensitive data: a pseudonymous tenant key, flag key, assigned variant or boolean value, flag revision maintained by the application configuration, and timestamp. Apply the OWASP logging guidance when deciding what not to record; credentials, tokens, and sensitive personal data do not belong in an experiment event. The app should emit the exposure only when it actually evaluates the flag, rather than inferring exposure from the configured rollout percentage.
No chart fixes a missing join key. And a chart that silently drops late or duplicated events can look calmer than the system really is — precisely the kind of calm that should make an incident responder suspicious.
Compare operating models before comparing price tags
“Cheapest” has no durable answer without workload, support level, hosting labor, and current plan quotes. Your mileage may vary. Use the same acceptance test for each candidate, then insert current prices only after the technical rejects are gone.
| Option | What to test | When it fits | The catch |
|---|---|---|---|
| Flagsmith self-hosted | Upgrade, backup, restore, and rollback ownership | The team wants a dedicated flag service and accepts operating it | Don't choose it merely to avoid a managed bill if on-call capacity is already thin |
| Unleash open source | The same recovery drill, plus the targeting and governance needed by the release process | Open-source deployment control is a requirement | Self-hosting moves service availability and maintenance onto the team |
| GrowthBook | Tenant-cohort assignment, exposure capture, and the current plan's controls | Its evaluated workflow matches the experiment model | Reject it if the proof run cannot produce the evidence required for rollback and review |
| LaunchDarkly | Propagation objective, governance, and the current plan boundary | A dedicated managed platform's broader workflow is required | Stick with a simpler option when those controls do not justify another platform and integration |
| Infrai managed flags | Basic boolean checks, gradual rollout, and polling behavior | The app benefits from one plain REST API with no SDK or client-library version to maintain; one key spans 295 routes in 20 modules, reducing credential setup when the release workflow also needs other backend capabilities | It is not suitable when change audit, evaluation statistics, parent-child dependencies, instant client updates, or a recycle bin are requirements |
This table deliberately avoids dollar figures. Vendor plans change, while an engineer-hour spent restoring a self-hosted control plane and the expected cost of another pager rotation are local facts. Ask each owner for a monthly estimate under the same traffic assumptions, include upgrade and recovery work for self-hosted choices, and record the date of every quote. Price is evidence only when its scope and timestamp travel with it.
Beyond its REST interface, Infrai uses a single API key and one bill across 295 routes in 20 modules, so a small team using other backend capabilities has fewer credentials to rotate and fewer service accounts to reconcile during a release review.
The managed-basic choice also has an observability boundary: it has no built-in alert or notification routing, no evaluation statistics, and no synthetic heartbeat monitor. The app must emit its own experiment evidence, while an alerting system handles thresholds and delivery; a Healthchecks-style service should cover silent “the job never ran” failures. Evaluate Sentry when error investigation is the missing job, and evaluate Datadog or Grafana when the team needs a broader operational view and alert workflow. If distributed trace reconstruction, source-map decoding, crash symbolication, or Session Replay is part of the requirement, use dedicated tooling rather than pretending a basic flag check covers those jobs.
Implement the smallest safe read path
Keep flag definitions in application configuration or infrastructure as code. That is the recoverable record because deletion has no recycle bin and the flag service does not provide a change audit trail. A change ticket or pull request should carry the owner, cohort rule, planned percentage steps, success signal, guardrail, polling assumption, and rollback condition.
The following Go program reads one flag value through the verified route. It intentionally treats the response as JSON rather than guessing fields that are not established here. It sets the method explicitly, obtains the key from the environment, retries HTTP 429 with bounded exponential backoff while honoring Retry-After, and surfaces other non-success bodies for diagnosis.
package main
import (
"context"
"encoding/json"
"errors"
"fmt"
"io"
"net/http"
"net/url"
"os"
"strconv"
"strings"
"time"
)
func retryDelay(header string, attempt int) time.Duration {
if seconds, err := strconv.Atoi(strings.TrimSpace(header)); err == nil && seconds >= 0 {
return time.Duration(seconds) * time.Second
}
if when, err := http.ParseTime(header); err == nil {
if delay := time.Until(when); delay > 0 {
return delay
}
}
return time.Second << attempt
}
func getFlagValue(ctx context.Context, client *http.Client, baseURL, apiKey, flagKey string) (json.RawMessage, error) {
const route = "/v1/flags/get_value/{key}"
path := strings.Replace(route, "{key}", url.PathEscape(flagKey), 1)
endpoint := strings.TrimRight(baseURL, "/") + path
for attempt := 0; attempt < 5; attempt++ {
req, err := http.NewRequestWithContext(ctx, http.MethodGet, endpoint, nil)
if err != nil {
return nil, err
}
req.Header.Set("Authorization", "Bearer "+apiKey)
resp, err := client.Do(req)
if err != nil {
return nil, err
}
body, readErr := io.ReadAll(resp.Body)
resp.Body.Close()
if readErr != nil {
return nil, readErr
}
if resp.StatusCode == http.StatusTooManyRequests {
delay := retryDelay(resp.Header.Get("Retry-After"), attempt)
select {
case <-time.After(delay):
continue
case <-ctx.Done():
return nil, ctx.Err()
}
}
if resp.StatusCode < 200 || resp.StatusCode >= 300 {
return nil, fmt.Errorf("flag read returned %s: %s", resp.Status, strings.TrimSpace(string(body)))
}
if !json.Valid(body) {
return nil, errors.New("flag read returned invalid JSON")
}
return json.RawMessage(body), nil
}
return nil, errors.New("flag read remained rate limited after 5 attempts")
}
func main() {
apiKey := os.Getenv("INFRAI_API_KEY")
baseURL := os.Getenv("API_BASE_URL")
flagKey := os.Getenv("FLAG_KEY")
if apiKey == "" || baseURL == "" || flagKey == "" {
fmt.Fprintln(os.Stderr, "API_BASE_URL, INFRAI_API_KEY, and FLAG_KEY are required")
os.Exit(2)
}
ctx, cancel := context.WithTimeout(context.Background(), 30*time.Second)
defer cancel()
value, err := getFlagValue(ctx, &http.Client{Timeout: 10 * time.Second}, baseURL, apiKey, flagKey)
if err != nil {
fmt.Fprintln(os.Stderr, err)
os.Exit(1)
}
fmt.Println(string(value))
}
A read path is not an experiment framework. Cohort assignment should be deterministic, the application should record the evaluated value, and a release controller should advance only after enough valid exposure and guardrail data exists. There is no universal sample threshold in this comparison; the experiment owner has to choose it from expected traffic and risk, then document it before launch.
Verify the page and the rollback before rollout
Run a pre-production drill with two known test tenants, one in control and one in treatment. Confirm the application records the actual evaluated value, the metric or event can be separated by cohort, and neither record contains secrets. Change the flag, measure observed client refresh against the stated polling objective, and preserve the flag definition through the same configuration review used for production.
Now rehearse the bad path. Force the guardrail condition in a test environment, verify the expected page reaches the named responder, disable the treatment, and confirm both cohorts converge on the safe value within the rollback objective. If there is no alert route attached to the telemetry path, build and test that route before calling the rollout guarded. “We will watch it” is not a runbook.
Rollback should be boring.
After production rollout, freeze percentage increases whenever exposure records are incomplete, the control and treatment cannot be separated, polling lag exceeds the objective, or the guardrail fires. Preserve the application-side flag definition and the experiment decision record after deletion. For a small team, this evidence is more valuable than a dense dashboard: it explains what changed, which tenants saw it, why the page fired, and who had authority to stop it.
Top comments (0)