DEV Community

Cover image for I Deployed on Friday and Broke Production. Here's What I Built to Never Do That Again.
Emmanuella A.
Emmanuella A.

Posted on

I Deployed on Friday and Broke Production. Here's What I Built to Never Do That Again.

#webdev #javascript #react #devops

The 3AM Wake-Up Call

It was a Friday afternoon. 4:47 PM. The new checkout flow was ready. Tests passed. Code review approved.

I hit deploy.

Everything looked fine for about 6 minutes.

Then Slack exploded. Payment processing was broken. Customers couldn't complete purchases. Revenue was literally stopping.

My hands were shaking as I tried to rollback. Git revert. Push. Wait for CI/CD.

22 minutes of downtime.

Twenty-two minutes of lost revenue. Twenty-two minutes of support tickets flooding in. Twenty-two minutes of pure panic.

That night, I couldn't sleep. Not because of the incident (those happen), but because I kept thinking: "There has to be a better way."

The Real Problem with Deployments

Here's the thing every developer knows but rarely admits:

We're all afraid to deploy on Fridays.

Not because we're bad at our jobs. Not because our code is untested. But because when something goes wrong, the "fix" is brutal:

  1. Realize there's a problem
  2. Figure out which commit caused it
  3. Revert the changes
  4. Wait for CI/CD (10-20 minutes minimum)
  5. Hope the rollback doesn't introduce new bugs
  6. Write incident report

The average "emergency rollback" takes 15-25 minutes.

In that time:

  • Revenue is lost
  • Users are frustrated
  • Your heart rate is through the roof
  • Your weekend is ruined

What I Learned the Hard Way

After that Friday incident, I started researching how big tech companies handle this.

Google deploys 50+ times per day. Amazon deploys every 11.6 seconds. Netflix pushes thousands of times daily.

Their secret? Feature flags.

But here's the catch: when I tried existing feature flag tools, I ran into new problems:

LaunchDarkly : specific amount/month for my 5-person team. Setup took 3+ hours reading documentation.

Flagsmith : Free, but required self-hosting, Docker setup, database configuration. Another weekend project.

ConfigCat : Better, but still required config files, environment variables, and complex SDK initialization.

For small teams and indie developers, these felt like bringing a bazooka to a water balloon fight.

I just wanted to:

  • Deploy safely
  • Rollback instantly if needed
  • Not spend $200/month or a weekend setting up infrastructure

So I built something simpler.

Introducing FlagSwift

After that 3AM wake-up call, I spent the next few weeks building what I wish I had that Friday:

The core idea : Feature flags that take 30 seconds to set up and let you rollback in 2 seconds.

Here's How It Works:

  1. Install (10 seconds) 
npm install @flagswift/react-client
Enter fullscreen mode Exit fullscreen mode
  1. Wrap your app (15 seconds) 
import { FlagProvider, FlagClient } from '@flagswift/react-client'

const client = new FlagClient({
  apiKey: process.env.NEXT_PUBLIC_FLAGSWIFT_API_KEY,
  environment: 'production'
})

function App() {
  return (
    <FlagProvider client={client}>
      <YourApp />
    </FlagProvider>
  )
}
Enter fullscreen mode Exit fullscreen mode
  1. Wrap any feature (5 seconds) 
function CheckoutPage() {
  const newCheckoutEnabled = useFlag('new-checkout-flow')

  return newCheckoutEnabled ? <NewCheckout /> : <OldCheckout />
}
Enter fullscreen mode Exit fullscreen mode

That's it. 30 seconds total.

Now when you deploy, the new checkout is hidden behind a flag. You control when it goes live.

The Magic: 2-Second Rollbacks.

Here's what would have saved me that Friday night :

Instead of:

  1. Git revert - 2 minutes
  2. Push to repo - 1 minute
  3. Wait for CI/CD - 15-20 minutes
  4. Pray it works - infinite anxiety

With FlagSwift :

  1. Open dashboard
  2. Click toggle
  3. Feature disabled globally

Total time: 2 seconds.

No deployment. No waiting. No git history pollution.

Real-World Example:

How This Saves You:
Let's say you're shipping a new payment flow (just like I was):

Without Feature Flags:

// Old code
function Checkout() {
  return <OldPaymentFlow />
}
Enter fullscreen mode Exit fullscreen mode

// Deploy new code - GOES LIVE IMMEDIATELY

function Checkout() {
  return <NewPaymentFlow />  // If this breaks, everyone sees it
}
Enter fullscreen mode Exit fullscreen mode

If it breaks: 15-25 minute rollback via deployment.

With FlagSwift:

function Checkout() {
  const useNewPayment = useFlag('new-payment-flow')

  return useNewPayment ? <NewPaymentFlow /> : <OldPaymentFlow />
}
Enter fullscreen mode Exit fullscreen mode

Deploy this code. Nothing changes for users yet.

Then:

  • Enable for yourself first (test in production with real data)
  • Enable for your QA team (5 people test it thoroughly)
  • Enable for 1% of users (50 people, monitor for issues)
  • Enable for 10% of users (500 people, looks good!)
  • Enable for everyone (full rollout)

If anything breaks at ANY step:
Click toggle. 2 seconds. Back to old flow.

What Makes FlagSwift Different
I've tried most feature flag tools.

Here's what I built differently:

** Zero Config**

  • No YAML files.
  • No environment variables (they're optional).
  • No complex setup.

One npm install, wrap your app, start using flags.

** It's Free to Start**

  • Unlimited flags
  • Unlimited environments
  • Unlimited team members

You only pay when you scale to high request volumes.

** User Targeting That Makes Sense**.
Want to test with specific users?

const client = new FlagClient({
  apiKey: 'your-key',
  userIdentifier: currentUser.email  // or user ID, whatever you want
})
Enter fullscreen mode Exit fullscreen mode

Add their email to the dashboard. Done.

  • No complicated segment rules.
  • No user attribute schemas.
  • Just identifiers.

** Multi-Environment by Default**

// Development
const client = new FlagClient({ environment: 'development' })

// Staging  
const client = new FlagClient({ environment: 'staging' })

// Production
const client = new FlagClient({ environment: 'production' })
Enter fullscreen mode Exit fullscreen mode

Test features locally while keeping them hidden in production.

Fast (Really Fast)

  • Your app checks flags instantly with zero network overhead per check.
  • Flags are fetched once on load and cached.
  • Dashboard changes propagate in ~2 seconds globally.

Current Status & What's Next

Right now, FlagSwift supports:

  • React (via @flagswift/react-client)
  • Node.js (via @flagswift/node-server)
  • Python (via pip install flagswift)

Coming soon:

  • Go SDK (for backend services)
  • Analytics dashboard (see which flags are actually used)
  • Slack notifications (get alerted when flags change)

Try It Yourself:

If you've ever been afraid to deploy on Friday, FlagSwift is for you.
FlagSwift

  • Free to start
  • 30-second setup
  • No credit card required
  • Rollback any feature in 2 seconds

I built this to solve my own 3AM deployment panic. Hope it helps you avoid yours.

What's your worst deployment story?
Mine was breaking checkout on a Friday afternoon and losing 22 minutes of revenue.

What's yours?
Drop it in the comments - let's commiserate together!
And when you try FlagSwift, I'd love to hear your feedback.
What works?
What doesn't?
What features would make this a must-have for your team?

Top comments (0)