Feature Flags Architecture for SaaS at Seed Stage
At pre-seed, feature flags are a single database table and a helper function. At seed stage, they become an operational system: multiple engineers committing flags, multiple customer segments targeted, A/B experiments running, and a growing backlog of flags that nobody has cleaned up yet.
The architectural decisions you make at seed stage determine whether your flag system scales cleanly to Series A or becomes a source of bugs, confusion, and engineering overhead. This guide covers the specific decisions that matter at seed stage — assuming you already have a basic flag implementation in place.
📐 What Changes at Seed Stage
| Capability | Pre-Seed | Seed Stage |
|---|---|---|
| Flag authorship | Solo founder controls all flags | Multiple engineers create and modify flags |
| Targeting | Simple on/off or internal team only | Percentage rollout, segment targeting, account-level rules |
| Flag types | Release flags only | Release, experiment, ops/kill switch, permission flags |
| Cleanup process | Ad hoc | Structured lifecycle with expiry dates and review cadence |
| Observability | Manual inspection | Flag evaluation metrics, flag-to-incident correlation |
🔧 Targeting Architecture
At seed stage, "on" and "off" are insufficient. You need targeting rules that let you roll out to a percentage of accounts, enable for specific customer segments, and keep features visible to internal teams while they are in development.
Four targeting contexts to implement at seed stage:
- → Internal segment — a list of account IDs belonging to your team and design partners. All new flags are enabled here first. This is non-negotiable; shipping a feature to external users before internal review is the most common cause of flag-related incidents.
- → Percentage rollout — enable for X% of accounts, selected by consistent hash of account ID. Start at 5%, observe error rates and support tickets, then increment. Account-level hashing (not user-level) ensures everyone in an account sees the same experience.
- → Explicit allowlist — a list of specific account IDs for beta access or design partner features. Separate from the percentage rollout so you can add specific accounts without affecting the rollout percentage.
- → Plan-based targeting — enable for accounts on specific subscription tiers. This is how you gate commercial features without hardcoding plan logic into application code.
🧪 A/B Experiments at Seed Stage
Seed stage is when A/B experiments first become meaningful — you have enough users to get statistical signal, and you have enough product surface to warrant testing. Feature flags are the infrastructure for A/B tests: the flag determines which variant a user sees.
Minimum requirements for a valid A/B experiment with flags:
- → Consistent assignment — a user always sees the same variant across sessions and devices. This requires hashing on a stable identifier (user ID or account ID), not a random value per request.
- → Metric instrumentation before launch — the event you are measuring (click, conversion, activation) must be tracked before you start the experiment. Retrofitting metrics after launch introduces selection bias.
- → Minimum sample size calculation — run an experiment only if you will reach statistical significance within 4 weeks at current traffic. Inconclusive experiments that run forever are worse than no experiment.
- → Clean experiment boundaries — do not let other changes (new onboarding, pricing changes, seasonal effects) overlap with a running experiment. Your signal will be contaminated.
🗓 Flag Lifecycle Management
Flag debt is the accumulation of flags that were created for a temporary purpose and never removed. At seed stage with 3–5 engineers creating flags, you can accumulate 50+ flags within a year without a lifecycle process. Each stale flag is a maintenance cost: it must be considered in every refactor, it confuses new engineers, and it creates unexpected behavior when it interacts with newer code.
The seed-stage flag lifecycle process:
- → Every flag created must have a type (release, experiment, kill switch, permission) and an expected removal date
- → Release flags are removed from code within 2 sprints of reaching 100% rollout — do not leave them in as permanent "off switches"
- → A monthly flag audit reviews flags past their expected date and assigns ownership for cleanup
- → Experiment flags are removed when the experiment concludes — winner shipped, loser removed, code cleaned up
What to Do Next
If you have flags but no targeting rules: implement the internal segment first — it is the highest-safety improvement with the least complexity. If you have targeting but no lifecycle process: add an expiry date field to your flags table and set a monthly calendar event for the flag audit. If your flag count is over 30: schedule a flag cleanup sprint before adding new flags and establish a naming convention review as part of the process.