← Back to Blog

Choosing the Right Tool: Lessons from 72 Hours of Infrastructure Hell

• by Alien Brain Trust • AI Learning
Choosing the Right Tool: Lessons from 72 Hours of Infrastructure Hell

Choosing the Right Tool: Lessons from 72 Hours of Infrastructure Hell

Meta Description: We wasted 72 hours on Azure before 20-minute Cloudflare fix. Here’s the decision framework we should have used.

Three days fighting Azure. Twenty minutes on Cloudflare. The technical details are in our previous posts. This one is about the decision-making failure that cost us three days.

The Mistake We Made

We chose Azure Static Web Apps because:

  1. We already had an Azure account
  2. We’d used Azure Functions before
  3. The documentation looked straightforward
  4. It was “free tier”

None of these are good reasons to choose a tool. They’re reasons of convenience and familiarity, not fit.

The Questions We Should Have Asked

1. What’s the Minimum Viable Infrastructure?

Our requirements:

  • Receive HTTP POST request
  • Validate JSON body
  • Make two API calls (Airtable, GitHub)
  • Return JSON response

That’s a single function. Not a “Static Web App with Managed Functions and GitHub Integration.” Not a platform. A function.

The simplest solutions:

  • Cloudflare Workers (what we used)
  • Vercel Serverless Functions
  • Netlify Functions
  • AWS Lambda with API Gateway
  • A $5/month VPS running Express

Azure Static Web Apps adds: deployment pipelines, configuration sprawl, portal/workflow sync, managed build systems. For what? A 100-line function.

Lesson: Match complexity to requirements. If you need a function, use a function platform, not a website platform with functions bolted on.

2. How Quickly Can I Verify the Deploy Pipeline?

This should have been our first test:

export default {
  async fetch(request) {
    return new Response('Hello World');
  }
};

Deploy it. Hit the endpoint. Confirm you see “Hello World.”

With Cloudflare Workers, this takes 2 minutes.

With Azure Static Web Apps, we didn’t have a working deploy pipeline after 72 hours. That should have been our signal on hour 2, not hour 72.

Lesson: Before writing business logic, prove you can deploy and see changes. If deploy is broken, nothing else matters.

3. Where Does Configuration Live?

In Cloudflare Workers, configuration lives in two places:

  1. wrangler.toml (project settings)
  2. Dashboard (secrets)

That’s it.

In Azure Static Web Apps, configuration can be in:

  1. staticwebapp.config.json (routing, headers)
  2. host.json (function runtime settings)
  3. function.json (per-function bindings)
  4. .github/workflows/*.yml (build/deploy settings)
  5. Azure Portal → Configuration (overrides? defaults? who knows)
  6. Azure Portal → Environment Variables
  7. Implicit defaults that aren’t documented

When something breaks, where do you look? Everywhere. And some settings override others in undocumented ways.

Lesson: Fewer configuration surfaces = faster debugging. Every config file is a potential source of mismatch.

4. What Do Error Messages Look Like?

Cloudflare Worker error:

INVALID_VALUE_FOR_COLUMN: Cannot parse value "testuser" for field GitHub User Name

Azure Static Web Apps error:

The content server has rejected the request with: BadRequest
Reason: No matching Static Web App was found or the api key was invalid.

The first tells you exactly what’s wrong (field type mismatch). The second could mean anything—wrong token, deleted resource, misconfigured workflow, wrong region, expired secret.

Lesson: Try to break the tool intentionally. See what error messages look like. If they’re useless, debugging production issues will be painful.

5. How Do I Add Secrets?

Cloudflare: Dashboard → Settings → Variables and Secrets → Add → Encrypt.

Azure Static Web Apps (our journey):

  • Started with environment variables in portal
  • Learned about Azure Key Vault for “proper” secret management
  • Needed Managed Identity to connect Key Vault to Functions
  • Realized Free tier might not support Managed Identity
  • Gave up and used plain environment variables
  • Environment variables didn’t propagate to deployed functions
  • Considered using GitHub Secrets + workflow variables
  • Never got far enough to test this because deploys kept failing

Lesson: Secret management should be trivial for simple use cases. If it requires multiple services and identity systems, you’re overengineered.

The Decision Framework We Use Now

Before choosing infrastructure, we now ask:

Fit Questions

  1. What’s the smallest thing that could work? (Start there)
  2. Does this tool add capabilities I’ll actually use? (If not, it’s complexity tax)
  3. Can I deploy hello world in under 10 minutes? (If not, red flag)

Debug Questions

  1. How many places can configuration live? (Fewer = better)
  2. What do error messages look like? (Test this intentionally)
  3. How do I view logs in production? (If it’s complicated, problems will be too)

Escape Questions

  1. How painful is migration if this doesn’t work? (Low lock-in = safety)
  2. What’s my fallback option? (Know it before you start)
  3. At what point do I abandon this and try the fallback? (Set a timebox)

If we’d asked these questions before starting, we would have:

  • Noticed Azure Static Web Apps has configuration in 6+ places
  • Tested deploy with hello world (and discovered it was broken)
  • Set a 4-hour timebox before trying alternatives
  • Had Cloudflare Workers as a documented fallback

Instead, we spent 72 hours because “we’d already invested time” and “Azure should work.”

The Sunk Cost Problem

This was our real failure. By hour 8, we should have asked: “Is continuing to debug Azure the best use of time?”

We didn’t because:

  • We’d already written the function code (sunk cost)
  • We’d already learned the config file formats (sunk cost)
  • We’d “almost” figured out the deploy (sunk cost)
  • Switching felt like admitting defeat (ego)

None of these are rational reasons to continue. The function code was portable. The config knowledge was worthless if deploys didn’t work. “Almost working” after 8 hours means fundamentally broken.

Lesson: Set explicit checkpoints. “If this isn’t working in 4 hours, we try the next option.” Treat it as process, not failure.

What We’d Do Differently

  1. Timebox the first attempt. 4 hours max before evaluating alternatives.

  2. Test deploy before writing code. Hello world first. Always.

  3. Document the fallback before starting. “If Azure doesn’t work, we’ll try Cloudflare Workers.” Having it written down makes the switch easier.

  4. Count configuration surfaces. More than 3? Probably overengineered for simple use cases.

  5. Value portability. Standard JavaScript functions are portable. Platform-specific bindings aren’t. Write portable code when possible.

The Silver Lining

We now have:

  • A working enrollment system on Cloudflare
  • A blog post series documenting the journey
  • A decision framework for future infrastructure choices
  • A strong opinion about Azure Static Web Apps (not for simple APIs)

And the Learn Labs course is live, which was the whole point.

Sometimes the long way teaches you more than the short way would have. But we’d still prefer to learn lessons in hours, not days.

Related posts: