Articles/App Development

▣ App Development/2026-03-30Advanced

Antigravity × Feature Flags & Progressive Delivery — Reduce Release Risk to Near Zero with AI Agents

How to build and operate Feature Flags and Progressive Delivery pipelines with Antigravity AI agents, with practical lessons from running indie apps totaling 50 million downloads.

antigravity⁴³⁵ feature-flags progressive-delivery canary-release a-b-testing² cicd⁸ devops⁴

✦ Premium Article

Setup and context — Release Anxiety Comes from Timing, Not the Code Itself

I've been running indie apps on the App Store and Google Play since 2014, and the catalog now adds up to more than 50 million downloads across wallpaper, mindfulness, and utility titles. After a decade of shipping into that surface area, the lesson I keep relearning is that release anxiety almost never comes from the code itself. It comes from not being able to decide when and to whom the code becomes visible.

I once pushed a new wallpaper generation pipeline to every user at once, and woke up to a slow but unmistakable rise in Out-of-Memory crashes on specific devices. Another time I changed the AdMob mediation order globally, and watched ARPDAU drop 30% in one revenue-critical segment overnight. The code itself was well tested. The problem was that the audience surface was too large to contain whatever the world threw at it.

Feature Flags decouple "deploying the code" from "exposing the code to users." A flag stays off until I explicitly turn it on, and the moment it flips back to off, the user-facing change disappears — no store re-submission, no redeploy, no waiting on review. That single property unlocks staged rollouts, canary releases, A/B tests, and emergency kill switches.

Progressive Delivery pushes the idea further: continuously watch metrics during rollout, and have the system flip the flag back to off automatically when a threshold is breached. Antigravity's AI agents have become deeply embedded in how I run this loop — they help generate flag code, assess release risk, watch metrics, and decide when to roll back.

Who this is for: intermediate-to-senior engineers comfortable with CI/CD who want a more disciplined release strategy. The pattern resonates especially with indie developers operating multiple production apps where a single bad release can ripple through the entire business.

Stack covered:

TypeScript / Node.js
Next.js (App Router)
Cloudflare Workers
Antigravity AI agents

What 50 Million Downloads Taught Me About the Reality of Flag Operations

Most books and conference talks frame Feature Flags around organizations with many teams shipping in parallel. Running 4–6 apps and 6 sites alone as an indie developer, the texture of flag operation looks a little different. Here are the things I only saw clearly after wiring flags into real production traffic.

First, the biggest gift flags offer isn't preventing incidents. It's the calm of knowing that if one happens, I can stop it with a single switch. When I ask Antigravity to add a new wallpaper category or change image generation logic, I now wrap it in a release flag before it ever reaches production. If something goes wrong, flipping the value in Cloudflare KV to false is enough to make the change disappear — no Apple or Google review involved. For AdMob SDK integration changes, where waiting on store review isn't an option, that low rollback cost is the difference between a contained incident and a revenue hit that takes a week to recover from.

Second, flags let me postpone decisions I shouldn't make yet. AdMob mediation order, push notification copy on mindfulness apps, alternative recommendation algorithms — for each of these I now ship behind a flag, expose it to a small slice of users, and let real data make the call. The psychological cost of releasing drops sharply once "hypothesis-mode" becomes a first-class option instead of an all-or-nothing bet.

Third, flags rot if you don't curate them. In my own logs, after three months of casual use, more than ten flags accumulated that nobody — including me — could explain anymore. Flag lifecycle management is something humans never finish on their own. The weekly Antigravity-driven audit script I describe later in the article is what makes long-running flag operation actually sustainable.

✦

Thank you for reading this far.

Continue Reading

What follows includes implementation code, benchmarks, and practical content we hope you'll find useful. This site runs without ads — server and development costs are supported entirely by members like you. If it's been helpful, we'd be truly grateful for your support.

WHAT YOU'LL LEARN

✦A blueprint for keeping flag evaluation latency under 5ms p50 at the Cloudflare Workers edge

✦A 1% → 5% → 25% → 50% → 100% rollout that hands off anomaly detection and automated rollback to Antigravity

✦Seven operational pitfalls that documentation skips — learned across 50M downloads of indie apps

Secure payment via Stripe · Cancel anytime

✦

Unlock This Article

Get full access to the rest of this article. Buy once, read anytime. This site is ad-free — your support goes directly toward keeping it running.

Unlock all articles with Membership →

Feature Flag Design Patterns — Understanding the Four Fundamental Types

Feature Flags can be broadly classified into four patterns based on their purpose. By explaining these patterns to Antigravity and having it generate project-specific implementations, you can dramatically accelerate development.

Release Flags are the most common pattern. You deploy new functionality within the codebase but control its visibility through a flag. Once the feature is stable, you remove the flag. These are short-lived — ideally removed within days to weeks.

Experiment Flags power A/B tests. Users are randomly assigned to groups that see different variants, allowing you to compare conversion rates and engagement. Once you have statistically significant results, adopt the winning variant and remove the flag.

Ops Flags dynamically modify system behavior. For example, they can act as kill switches that temporarily disable specific features during high load. These may persist for extended periods.

Permission Flags provide features to specific user groups only. They're used for premium feature gating and beta tester early access.

// feature-flags.ts — Type-safe Feature Flag system foundation
// Ask Antigravity: "Create a type-safe Feature Flag manager"
// and it will auto-generate a structure like this
 
type FlagType = 'release' | 'experiment' | 'ops' | 'permission';
 
interface FeatureFlag<T = boolean> {
  key: string;
  type: FlagType;
  defaultValue: T;
  description: string;
  owner: string;        // Responsible team (for lifecycle management)
  createdAt: string;
  expiresAt?: string;   // Release flags must always have an expiry
}
 
interface FlagEvaluationContext {
  userId: string;
  userAttributes: Record<string, string | number | boolean>;
  environment: 'production' | 'staging' | 'development';
  percentage?: number;  // For staged rollouts (0-100)
}
 
// Centralized flag definitions
const FLAGS = {
  newCheckoutFlow: {
    key: 'new-checkout-flow',
    type: 'release' as FlagType,
    defaultValue: false,
    description: 'New checkout flow UI',
    owner: 'payment-team',
    createdAt: '2026-03-30',
    expiresAt: '2026-04-30', // Must evaluate within 1 month
  },
  pricingExperiment: {
    key: 'pricing-experiment',
    type: 'experiment' as FlagType,
    defaultValue: 'control', // 'control' | 'variant-a' | 'variant-b'
    description: 'Pricing page A/B test',
    owner: 'growth-team',
    createdAt: '2026-03-30',
  },
  emergencyReadOnly: {
    key: 'emergency-read-only',
    type: 'ops' as FlagType,
    defaultValue: false,
    description: 'Emergency read-only mode',
    owner: 'sre-team',
    createdAt: '2026-03-30',
  },
} as const;
 
// Output:
// FLAGS.newCheckoutFlow.key → 'new-checkout-flow'
// FLAGS.pricingExperiment.type → 'experiment'

Ask Antigravity to "generate a custom React hook from these flag definitions," and it will create a type-safe useFeatureFlag() hook automatically.

Automated Feature Flag Code Generation with Antigravity Agents

Antigravity's powerful AI agents can efficiently generate boilerplate Feature Flag code — evaluation logic, React hooks, and server-side middleware. Here's a practical workflow.

First, it's crucial to define flag management rules in your AGENTS.md. This ensures the agent follows consistent patterns when creating flags.

<!-- .antigravity/rules/feature-flags.md -->
# Feature Flag Rules
 
## Naming Convention
- Use kebab-case: `new-checkout-flow`
- Prefix by type: `exp-` (experiment), `ops-` (operations), `perm-` (permission)
- Release flags have no prefix
 
## Required Fields
- All flags must have `owner` and `createdAt`
- Release flags must have `expiresAt` (max 30 days)
- Experiment flags must define `variants` and `metrics`
 
## Flag Removal
- Expired flags must be removed in the next sprint
- Remove related test code when removing a flag

Then, ask Antigravity to generate specific flag implementations.

// hooks/useFeatureFlag.ts — Custom hook generated by Antigravity
// Agent prompt: "Create a Feature Flag hook using Cloudflare KV as backend"
 
import { useEffect, useState } from 'react';
 
interface FlagConfig {
  key: string;
  defaultValue: boolean;
  userId?: string;
}
 
export function useFeatureFlag({ key, defaultValue, userId }: FlagConfig): {
  enabled: boolean;
  loading: boolean;
} {
  const [enabled, setEnabled] = useState(defaultValue);
  const [loading, setLoading] = useState(true);
 
  useEffect(() => {
    const controller = new AbortController();
 
    async function fetchFlag() {
      try {
        const params = new URLSearchParams({ key });
        if (userId) params.append('userId', userId);
 
        const res = await fetch(`/api/flags?${params}`, {
          signal: controller.signal,
        });
 
        if (res.ok) {
          const data = await res.json();
          setEnabled(data.enabled);
        }
      } catch (err) {
        if (err instanceof DOMException && err.name === 'AbortError') return;
        console.warn(`Flag evaluation failed for ${key}, using default`);
      } finally {
        setLoading(false);
      }
    }
 
    fetchFlag();
    return () => controller.abort();
  }, [key, userId]);
 
  return { enabled, loading };
}
 
// Usage in a component:
// const { enabled: showNewUI, loading } = useFeatureFlag({
//   key: 'new-checkout-flow',
//   defaultValue: false,
//   userId: session.userId,
// });
// if (loading) return <Skeleton />;
// return showNewUI ? <NewCheckout /> : <LegacyCheckout />;

Building a Flag Evaluation Engine on Cloudflare Workers

Evaluating Feature Flags at the edge minimizes latency. Let's build a flag evaluation engine using Cloudflare Workers + KV, working alongside Antigravity agents.

// api/flags/route.ts — Edge-powered flag evaluation API
// Have Antigravity generate the scaffold, then add business logic
 
import { NextRequest, NextResponse } from 'next/server';
import { getCloudflareContext } from '@opennextjs/cloudflare';
 
interface FlagRule {
  enabled: boolean;
  percentage?: number;     // Staged rollout: 0-100
  allowList?: string[];    // Specific user whitelist
  startDate?: string;      // Scheduled release start
  endDate?: string;        // Scheduled release end
}
 
function hashUserId(userId: string, flagKey: string): number {
  // Deterministic hash: same user always gets the same result
  let hash = 0;
  const input = `${userId}:${flagKey}`;
  for (let i = 0; i < input.length; i++) {
    const char = input.charCodeAt(i);
    hash = ((hash << 5) - hash) + char;
    hash = hash & hash; // Convert to 32-bit integer
  }
  return Math.abs(hash) % 100;
}
 
export async function GET(request: NextRequest) {
  const { searchParams } = new URL(request.url);
  const key = searchParams.get('key');
  const userId = searchParams.get('userId');
 
  if (!key) {
    return NextResponse.json({ error: 'key is required' }, { status: 400 });
  }
 
  try {
    const { env } = await getCloudflareContext();
    const raw = await env.FLAGS_KV.get(`flag:${key}`);
 
    if (!raw) {
      return NextResponse.json({ enabled: false, source: 'default' });
    }
 
    const rule: FlagRule = JSON.parse(raw);
 
    // Allowlist check
    if (userId && rule.allowList?.includes(userId)) {
      return NextResponse.json({ enabled: true, source: 'allowList' });
    }
 
    // Schedule check
    const now = new Date();
    if (rule.startDate && now < new Date(rule.startDate)) {
      return NextResponse.json({ enabled: false, source: 'scheduled' });
    }
    if (rule.endDate && now > new Date(rule.endDate)) {
      return NextResponse.json({ enabled: false, source: 'expired' });
    }
 
    // Percentage-based rollout
    if (rule.percentage !== undefined && userId) {
      const bucket = hashUserId(userId, key);
      const enabled = bucket < rule.percentage;
      return NextResponse.json({ enabled, source: 'percentage', bucket });
    }
 
    return NextResponse.json({ enabled: rule.enabled, source: 'rule' });
  } catch (err) {
    console.error('Flag evaluation error:', err);
    return NextResponse.json({ enabled: false, source: 'error' });
  }
}
 
// Example KV data:
// key: "flag:new-checkout-flow"
// value: {"enabled":true,"percentage":10,"allowList":["user-beta-1"]}
// → Shows new UI to 10% of users + beta testers

The key feature is the hashUserId function for deterministic assignment. The same user always sees the same variant, ensuring stable A/B test results.

Implementing Canary Releases — Safe, Staged Rollouts

A canary release exposes a new version to a small subset of users first, then gradually expands if no issues arise. Let's build a pipeline that automatically controls rollout rates using Antigravity agents.

// scripts/canary-rollout.ts — Rollout script managed by Antigravity agents
// Prompt: "Create an automated canary rollout script"
 
interface RolloutStage {
  percentage: number;
  duration: string;      // How long to maintain this stage
  successCriteria: {
    maxErrorRate: number;  // Maximum acceptable error rate (%)
    maxLatencyP99: number; // Maximum P99 latency (ms)
    minSuccessRate: number; // Minimum success rate (%)
  };
}
 
const ROLLOUT_PLAN: RolloutStage[] = [
  {
    percentage: 1,
    duration: '30m',
    successCriteria: { maxErrorRate: 0.1, maxLatencyP99: 500, minSuccessRate: 99.9 },
  },
  {
    percentage: 5,
    duration: '1h',
    successCriteria: { maxErrorRate: 0.5, maxLatencyP99: 800, minSuccessRate: 99.5 },
  },
  {
    percentage: 25,
    duration: '2h',
    successCriteria: { maxErrorRate: 1.0, maxLatencyP99: 1000, minSuccessRate: 99.0 },
  },
  {
    percentage: 50,
    duration: '4h',
    successCriteria: { maxErrorRate: 1.0, maxLatencyP99: 1000, minSuccessRate: 99.0 },
  },
  {
    percentage: 100,
    duration: 'permanent',
    successCriteria: { maxErrorRate: 1.0, maxLatencyP99: 1200, minSuccessRate: 98.5 },
  },
];
 
async function evaluateMetrics(flagKey: string): Promise<{
  errorRate: number;
  latencyP99: number;
  successRate: number;
}> {
  // In practice, fetch from monitoring tools (Grafana, Datadog, etc.)
  // Antigravity generates implementation matching your monitoring stack
  const response = await fetch(`https://monitoring.example.com/api/metrics`, {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify({
      query: `feature_flag{key="${flagKey}"}`,
      range: '15m',
    }),
  });
  return response.json();
}
 
async function updateFlagPercentage(flagKey: string, percentage: number): Promise<void> {
  // Update the flag value in Cloudflare KV
  await fetch(`https://api.cloudflare.com/client/v4/accounts/{account_id}/storage/kv/namespaces/{namespace_id}/values/flag:${flagKey}`, {
    method: 'PUT',
    headers: {
      'Authorization': `Bearer YOUR_API_KEY`,
      'Content-Type': 'application/json',
    },
    body: JSON.stringify({ enabled: true, percentage }),
  });
}
 
async function rollback(flagKey: string, reason: string): Promise<void> {
  console.error(`🚨 ROLLBACK: ${flagKey} — ${reason}`);
  await updateFlagPercentage(flagKey, 0);
  // Send Slack / Discord notification
  // Ask Antigravity: "Add Slack notification support" for auto-implementation
}
 
async function executeRollout(flagKey: string): Promise<void> {
  for (const stage of ROLLOUT_PLAN) {
    console.log(`📊 Stage: ${stage.percentage}% rollout`);
    await updateFlagPercentage(flagKey, stage.percentage);
 
    // Wait for the specified duration to collect metrics
    const waitMs = parseDuration(stage.duration);
    if (waitMs === Infinity) break; // permanent = final stage
 
    await new Promise(resolve => setTimeout(resolve, waitMs));
 
    // Evaluate metrics
    const metrics = await evaluateMetrics(flagKey);
 
    if (metrics.errorRate > stage.successCriteria.maxErrorRate) {
      await rollback(flagKey, `Error rate ${metrics.errorRate}% exceeds threshold ${stage.successCriteria.maxErrorRate}%`);
      return;
    }
    if (metrics.latencyP99 > stage.successCriteria.maxLatencyP99) {
      await rollback(flagKey, `P99 latency ${metrics.latencyP99}ms exceeds threshold ${stage.successCriteria.maxLatencyP99}ms`);
      return;
    }
    if (metrics.successRate < stage.successCriteria.minSuccessRate) {
      await rollback(flagKey, `Success rate ${metrics.successRate}% below threshold ${stage.successCriteria.minSuccessRate}%`);
      return;
    }
 
    console.log(`✅ Stage ${stage.percentage}% passed — metrics OK`);
  }
 
  console.log('🎉 Rollout complete — 100% traffic');
}
 
function parseDuration(d: string): number {
  if (d === 'permanent') return Infinity;
  const match = d.match(/^(\d+)(m|h)$/);
  if (!match) throw new Error(`Invalid duration: ${d}`);
  const [, num, unit] = match;
  return parseInt(num) * (unit === 'h' ? 3600000 : 60000);
}
 
// Execution:
// executeRollout('new-checkout-flow');
// → 1% → 5% → 25% → 50% → 100% staged rollout
// → Automatic metrics check at each stage; instant rollback on anomalies

The critical element is pre-defining successCriteria for each stage. Ask Antigravity to "analyze past deployment metrics and suggest appropriate thresholds," and it will propose realistic values based on your project's actual performance history.

A/B Test Design and Statistical Testing

Another powerful application of Feature Flags is A/B testing. Let's explore how to statistically measure the impact of UI changes on conversion rates.

// lib/ab-testing.ts — A/B test management module
// Prompt: "Implement an A/B testing library with statistical significance testing"
 
interface Experiment {
  key: string;
  variants: string[];     // ['control', 'variant-a', 'variant-b']
  trafficAllocation: number; // Traffic percentage in the experiment (0-100)
  metrics: string[];      // Metric names to track
}
 
interface ExperimentResult {
  variant: string;
  sampleSize: number;
  conversions: number;
  conversionRate: number;
}
 
// Z-test for statistical significance
function calculateZScore(
  control: ExperimentResult,
  treatment: ExperimentResult
): { zScore: number; pValue: number; significant: boolean } {
  const p1 = control.conversionRate;
  const p2 = treatment.conversionRate;
  const n1 = control.sampleSize;
  const n2 = treatment.sampleSize;
 
  // Pooled proportion
  const pooled = (control.conversions + treatment.conversions) / (n1 + n2);
  const se = Math.sqrt(pooled * (1 - pooled) * (1 / n1 + 1 / n2));
 
  if (se === 0) return { zScore: 0, pValue: 1, significant: false };
 
  const zScore = (p2 - p1) / se;
 
  // Two-tailed p-value (approximation)
  const pValue = 2 * (1 - normalCDF(Math.abs(zScore)));
 
  return {
    zScore,
    pValue,
    significant: pValue < 0.05, // 95% confidence level
  };
}
 
function normalCDF(x: number): number {
  // Standard normal CDF (Abramowitz & Stegun approximation)
  const t = 1 / (1 + 0.2316419 * Math.abs(x));
  const d = 0.3989422804014327;
  const p =
    d * Math.exp(-x * x / 2) *
    (t * (0.3193815 + t * (-0.3565638 + t * (1.781478 + t * (-1.821256 + t * 1.330274)))));
  return x > 0 ? 1 - p : p;
}
 
// Pre-calculate required sample size
function requiredSampleSize(
  baselineRate: number,        // Current conversion rate
  minimumDetectableEffect: number, // Smallest effect you want to detect
  power: number = 0.8,         // Statistical power (typically 80%)
  alpha: number = 0.05         // Significance level (typically 5%)
): number {
  const zAlpha = 1.96;  // z-value for α=0.05
  const zBeta = 0.842;  // z-value for β=0.2 (power=0.8)
  const p1 = baselineRate;
  const p2 = baselineRate + minimumDetectableEffect;
  const pBar = (p1 + p2) / 2;
 
  const n = Math.ceil(
    (Math.pow(zAlpha + zBeta, 2) * (p1 * (1 - p1) + p2 * (1 - p2))) /
    Math.pow(p2 - p1, 2)
  );
 
  return n;
}
 
// Output:
// requiredSampleSize(0.03, 0.005)
// → Approximately 14,752 (samples needed per variant)
// To detect a 0.5 percentage point improvement from a 3% baseline CVR,
// you need ~15,000 samples per variant

Tell Antigravity your project's current conversion rates and ask it to "estimate the required sample size and experiment duration." It will automatically create an experiment plan, preventing the waste of running experiments that lack statistical power.

AI-Driven Release Risk Analysis — Predict Issues Before Deployment

Antigravity agents truly shine in pre-release risk analysis. Build a workflow that analyzes code diffs, cross-references past incident patterns, and evaluates release risk before deployment.

// scripts/release-risk-analysis.ts — AI-driven release risk analysis
// Run in Antigravity's Agent mode for full codebase-aware analysis
 
interface RiskFactor {
  category: 'code' | 'dependency' | 'config' | 'database' | 'infrastructure';
  severity: 'low' | 'medium' | 'high' | 'critical';
  description: string;
  mitigation: string;
}
 
interface ReleaseRiskReport {
  overallRisk: 'low' | 'medium' | 'high' | 'critical';
  factors: RiskFactor[];
  recommendedRolloutStrategy: string;
  flagsToCreate: string[];
  testsCoverage: {
    newCode: number;      // Test coverage for new code
    modifiedCode: number; // Test coverage for modified code
  };
}
 
// Prompt template for Antigravity agent (add to AGENTS.md)
const RISK_ANALYSIS_PROMPT = `
## Release Risk Analysis Task
 
Analyze the code diff from the following perspectives and generate a risk report:
 
1. **Code Risk**
   - Impact scope (number of files, functions)
   - Complexity changes (cyclomatic complexity)
   - Error handling completeness
   - Type safety verification
 
2. **Dependency Risk**
   - New external dependencies added
   - Major version updates
   - Security advisories
 
3. **Configuration Risk**
   - Environment variable additions/changes
   - Infrastructure configuration changes
   - Feature Flag additions
 
4. **Database Risk**
   - Migrations present
   - Breaking schema changes
   - Data backfill requirements
 
5. **Recommended Rollout Strategy**
   - Staged rollout plan based on risk level
   - List of Feature Flags to create
   - Rollback procedure proposals
`;
 
// GitHub Actions config for automated risk analysis
// Have Antigravity generate .github/workflows/release-risk.yml

In practice, whenever a pull request is created, the Antigravity agent analyzes the code diff and posts a risk report as a comment. This allows reviewers to focus on high-risk changes, significantly improving review efficiency.

Implementing Automated Rollback

The final piece of Progressive Delivery is automated rollback when issues are detected. Build a system that instantly rolls back without human intervention when metric anomalies are found.

// lib/auto-rollback.ts — Metric monitoring and automated rollback
// Prompt: "Implement auto-rollback using Cloudflare Analytics API"
 
interface MetricThreshold {
  metric: string;
  operator: 'gt' | 'lt' | 'gte' | 'lte';
  value: number;
  window: string;  // Evaluation window: '5m', '15m', '1h'
}
 
interface RollbackPolicy {
  flagKey: string;
  thresholds: MetricThreshold[];
  cooldownMinutes: number;  // Re-enable lockout after rollback
  notifyChannels: string[];
}
 
const ROLLBACK_POLICIES: RollbackPolicy[] = [
  {
    flagKey: 'new-checkout-flow',
    thresholds: [
      { metric: 'error_rate', operator: 'gt', value: 2.0, window: '5m' },
      { metric: 'p99_latency_ms', operator: 'gt', value: 2000, window: '5m' },
      { metric: 'checkout_success_rate', operator: 'lt', value: 95, window: '15m' },
    ],
    cooldownMinutes: 60,
    notifyChannels: ['slack:payments-alerts', 'pagerduty:checkout'],
  },
];
 
async function monitorAndRollback(policy: RollbackPolicy): Promise<void> {
  const checkInterval = 60_000; // Check every minute
 
  while (true) {
    await new Promise(r => setTimeout(r, checkInterval));
 
    for (const threshold of policy.thresholds) {
      const currentValue = await getMetricValue(
        threshold.metric,
        threshold.window
      );
 
      const violated = evaluateThreshold(currentValue, threshold);
 
      if (violated) {
        console.error(
          `🚨 Threshold violated: ${threshold.metric} = ${currentValue} ` +
          `(${threshold.operator} ${threshold.value})`
        );
 
        // Immediate rollback
        await executeRollback(policy.flagKey);
 
        // Send notifications
        for (const channel of policy.notifyChannels) {
          await sendNotification(channel, {
            type: 'rollback',
            flagKey: policy.flagKey,
            reason: `${threshold.metric} = ${currentValue}`,
            timestamp: new Date().toISOString(),
          });
        }
 
        // Cooldown period
        console.log(`⏸️ Cooldown: ${policy.cooldownMinutes}m`);
        await new Promise(r =>
          setTimeout(r, policy.cooldownMinutes * 60_000)
        );
        break;
      }
    }
  }
}
 
function evaluateThreshold(
  value: number,
  threshold: MetricThreshold
): boolean {
  switch (threshold.operator) {
    case 'gt':  return value > threshold.value;
    case 'lt':  return value < threshold.value;
    case 'gte': return value >= threshold.value;
    case 'lte': return value <= threshold.value;
  }
}
 
async function getMetricValue(metric: string, window: string): Promise<number> {
  // Fetch from Cloudflare Analytics API or external monitoring tools
  // Implementation auto-generated by Antigravity based on your infra
  return 0;
}
 
async function executeRollback(flagKey: string): Promise<void> {
  // Disable the flag in KV
  console.log(`🔄 Rolling back flag: ${flagKey}`);
}
 
async function sendNotification(
  channel: string,
  payload: Record<string, string>
): Promise<void> {
  // Notify via Slack / PagerDuty / Discord
  console.log(`📢 Notification sent to ${channel}`);
}
 
// Output when rollback triggers:
// 🚨 Threshold violated: error_rate = 3.2 (gt 2.0)
// 🔄 Rolling back flag: new-checkout-flow
// 📢 Notification sent to slack:payments-alerts
// 📢 Notification sent to pagerduty:checkout
// ⏸️ Cooldown: 60m

Flag Lifecycle Management — Preventing Technical Debt

Feature Flags are powerful, but left unmanaged they become technical debt. Let's use Antigravity agents to automate flag lifecycle management.

// scripts/flag-hygiene.ts — Detect and remove expired flags
// Prompt: "Create a script that detects expired Feature Flags"
 
import { readFileSync, readdirSync } from 'fs';
import { join } from 'path';
 
interface FlagAuditResult {
  key: string;
  status: 'active' | 'expired' | 'stale' | 'orphaned';
  expiresAt?: string;
  usageCount: number;   // References in codebase
  lastModified: string; // Last modification date
  recommendation: string;
}
 
async function auditFlags(projectRoot: string): Promise<FlagAuditResult[]> {
  const results: FlagAuditResult[] = [];
  const now = new Date();
 
  // Load flag definitions
  const flagDefs = loadFlagDefinitions(projectRoot);
 
  for (const flag of flagDefs) {
    // Count references in codebase
    const usageCount = countFlagUsages(projectRoot, flag.key);
 
    // Determine status
    let status: FlagAuditResult['status'] = 'active';
    let recommendation = '';
 
    if (flag.expiresAt && new Date(flag.expiresAt) < now) {
      status = 'expired';
      recommendation = `Expired on ${flag.expiresAt}. Remove the flag and related code.`;
    } else if (usageCount === 0) {
      status = 'orphaned';
      recommendation = 'Not referenced in code. Delete the definition.';
    } else if (daysSince(flag.createdAt) > 90 && flag.type === 'release') {
      status = 'stale';
      recommendation = 'Release flag older than 90 days. Consider making permanent or removing.';
    }
 
    results.push({
      key: flag.key,
      status,
      expiresAt: flag.expiresAt,
      usageCount,
      lastModified: flag.createdAt,
      recommendation,
    });
  }
 
  return results;
}
 
function countFlagUsages(root: string, flagKey: string): number {
  // Count occurrences via grep
  // In practice, Antigravity agent searches the entire project
  let count = 0;
  const srcDir = join(root, 'src');
  // Recursively scan files and count flagKey occurrences
  return count;
}
 
function daysSince(dateStr: string): number {
  return Math.floor(
    (Date.now() - new Date(dateStr).getTime()) / (1000 * 60 * 60 * 24)
  );
}
 
function loadFlagDefinitions(root: string): any[] {
  // Load project's flag definitions
  return [];
}
 
// Run weekly in CI and post report to Slack:
// npx tsx scripts/flag-hygiene.ts
//
// Output:
// 🔍 Flag Audit Report — 2026-03-30
// ────────────────────────────────
// ❌ EXPIRED: new-checkout-flow (expired 2026-03-28)
//    → Remove the flag and related code
// ⚠️ STALE: legacy-api-fallback (created 120 days ago)
//    → Older than 90 days. Consider making permanent or removing
// ✅ ACTIVE: exp-pricing-v2 (expires 2026-04-15, 23 references)
// ✅ ACTIVE: ops-maintenance-mode (no expiry, 5 references)

You can configure Antigravity agents to run this script periodically and auto-create pull requests when expired flags are detected. Simply instruct "Remove all code for the new-checkout-flow flag and always show the new UI," and it handles conditional branch removal, test code updates, and flag definition deletion in one pass.

Seven Operational Pitfalls the Documentation Doesn't Mention

These are the seven traps that vendor docs and textbooks tend to leave out — most of which I learned the hard way. Loading them into Antigravity's context as guardrails up front saves the agent (and you) from rediscovering them on production traffic.

1. Watch the p99 of flag evaluation, not the mean. A 3ms average looks fine until you realize the 99th percentile is spiking to 200ms in cold-read regions. On Cloudflare Workers + KV, I always graph p99 and fall back to an in-memory cache for evaluation when it crosses a threshold.

2. Never change the user-ID hash once you've shipped it. Staged rollouts depend on a deterministic hash to decide who's in the 50%. If you change the hash algorithm or seed mid-flight, the set of "exposed" users gets reshuffled, and people who saw the new experience yesterday lose access today. That's the single worst UX failure mode I've inflicted on real users with flags.

3. Don't delete the legacy branch the moment the flag goes 100%. I once cleaned up the "old code path" right after a flag reached full rollout, only to want it back during a regional outage hours later. The discipline I now follow: keep both branches alive for at least one release after a flag is removed.

4. Read A/B test results from the last seven days, not the first three. New experiences carry a novelty bump that fades. Every wallpaper category I've launched showed a 1.5× CTR for the first three days before settling into its true baseline a week later. Decide on rollout from the steady state, not the launch peak.

5. "Paid-users-only" flags have to assume webhook latency. Stripe or RevenueCat webhooks can lag a few seconds, and evaluating the flag in that window classifies a paying user as free. I handle this by optimistically enabling paid-only features on the client right after checkout, then reconciling against authoritative server state shortly after.

6. Anything that requires store review can't truly be flagged. Native push notification behavior, AdMob SDK integration changes, and similar surfaces escape the reach of Feature Flags. I now draw a clear line on day one between "server-flippable" and "store-review-bound" behavior, so flag strategy doesn't get conflated with promises it can't keep.

7. Antigravity-only operation pushes flag counts upward. AI agents generate freely but rarely propose deletion without explicit prompting. The rules I keep in the agent's persistent context — "any expired flag must yield a removal PR within the week" and "three flags in the same category should trigger a consolidation proposal" — visibly slow the drift toward flag entropy.

These pitfalls are the kind you usually have to feel once before they stick, but giving them to Antigravity as part of its operating ruleset means most of them never have to happen in the first place.

Practical Workflow — Integrating Progressive Delivery into Daily Development

Here's how to integrate all the patterns we've covered into your daily development workflow.

Step 1: Starting feature development — Ask Antigravity to "create a Feature Flag for new feature X." The agent generates flag definitions, React hooks, server-side evaluation logic, and test code in one batch.

Step 2: During development — Develop while toggling between old and new implementations via the flag. Keep the flag always enabled in development and use random assignment in staging for testing.

Step 3: Code review — Antigravity's risk analysis auto-comments on the PR, suggesting the recommended rollout strategy.

Step 4: Deployment — Merging to main triggers automatic CI/CD deployment. But since the flag is OFF, there's zero user impact.

Step 5: Canary release — Gradually increase the flag's rollout rate: 1% → 5% → 25% → 50% → 100%. Metrics are automatically monitored at each stage with instant rollback on anomalies.

Step 6: Cleanup — After 100% rollout, the flag hygiene script detects the expiry and auto-creates a PR for removal.

With Antigravity supporting this entire flow, you minimize manual overhead while ensuring safe, reliable releases.

A Case Study — Before / After in a Wallpaper App Category Launch

To make this concrete, here's how a single category addition in one of my wallpaper apps changed once Feature Flags entered the workflow.

Before flags: I'd ship a finished category by submitting a new binary, waiting through Apple's 1–3 day review, and pushing live to every user at once. The only rollback path was a binary resubmission, which on Google Play once stretched to four days. In one launch, I noticed an OutOfMemoryError spike on a new image-generation category 14 hours after public release. By the time the rollback build was approved, the app's rating had drifted from 4.6 to 4.4 — and that decimal point came back slowly.

After flags: I asked Antigravity to wrap the same category in a release flag and to schedule a 1% → 5% → 25% → 100% rollout spaced 24 hours apart. The agent produced the flag definition, the client-side gating, and a small admin API for adjusting rollout percentage. Memory consumption crossed the threshold again on this launch — but the Cloudflare Workers metrics fired the alert while rollout was still at 5%. Flipping the flag to false ended user exposure immediately. No store review, no resubmission. The fix shipped behind the same flag the next morning, starting again at 1%.

The pattern shifted my release cadence as much as my risk profile. Before flags, the psychological cost of new category launches was high enough that I averaged roughly one new category every two months. After flags, I'm comfortable trying a new category every week. The headline insight isn't "flags prevent disasters" — it's "flags let me take more swings safely."

Closing Thoughts

After weaving Feature Flags and Progressive Delivery into Antigravity's workflow, I've come to think of them less as cutting-edge engineering and more as a mental-health tool for whoever owns releases. Once the loop is built, it's much easier to look at a noisy metric at 2 a.m. and remember that everything is one button away from being undone.

I started with a single release flag. The first few weeks were mostly about getting comfortable with the act of flipping flags on and off. Canary releases, A/B tests, and emergency kill switches arrived gradually after that. The downstream effect on both the app business and the writing business has been a meaningful increase in how often I'm willing to step up to the plate.

If you're starting from zero, I'd recommend something counterintuitive: wrap an existing, already-shipped feature in a flag before reaching for a new one. Practicing rollback on a feature you already trust is a lower-risk way to develop the instinct than learning it on a feature you're nervous about in the first place.

Thank you for reading this far. I hope it's useful for fellow indie developers running more than one product at a time.

For related reading, Advanced CI/CD Pipeline with GitHub Actions goes deeper on CI/CD automation, and Building an Observability Pipeline with OpenTelemetry covers the metrics infrastructure that makes Progressive Delivery's monitoring loop trustworthy.

Thank You for Reading

Antigravity Lab is ad-free, supported entirely by members like you. We publish practical guides daily with implementation code, benchmarks, and production-ready patterns. If you've found it useful, we'd love to have you on board.