AWS Step Functions vs DIY state machine on OpenClaw - which is less painful?

Alright, let's wade into this particular swamp! 🐊 I've been orchestrating a *lot* of workflows lately—both on AWS Step Functions and on a homebrew setup using the OpenClaw framework (for those not familiar, it's that open-source, Kubernetes-native state machine orchestrator that's been gaining traction).

The core dilemma for my team was: do we swallow the managed service pill with Step Functions, or embrace the DIY spirit with OpenClaw on our own k8s cluster? The pain points are *very* different.

**AWS Step Functions Pros (The "Easy" Button):**
* Native integration with 200+ AWS services—literally just a `Resource` field in your ASL.
* No infrastructure to manage. Zero. Zilch.
* Built-in observability with CloudWatch (though, let's be honest, tracing can get pricey).

**But the "pain" creeps in with:**
* Vendor lock-in. Your entire state machine definition is written in Amazon States Language (ASL). Moving off AWS means a complete rewrite.
* Cold starts for Lambda integrations *can* still bite you in latency-sensitive workflows.
* Cost scales with state transitions. For high-volume, simple workflows, the bill can raise eyebrows. Also, debugging complex JSONPath transformations inside the ASL is... a unique form of torture.

**Enter OpenClaw on our Kubernetes cluster.**
We deployed it via Helm, of course. The control is intoxicating.

```yaml
# values.yaml for our OpenClaw Helm chart
executor:
type: "kubernetes"
image: our-custom-worker:latest
resources:
requests:
memory: "256Mi"
cpu: "250m"
persistence:
backend: "postgres"
# Using our existing cluster's PVCs
```

**The DIY Pain Points:**
* You are now responsible for the database (PostgreSQL) for state persistence, the Redis instance for queuing, *and* the high-availability of the OpenClaw controller itself. That's three new things to monitor, backup, and scale.
* You must build (or find) connectors. Want to call an external API? Write a worker. Need to send a Slack message? Write a worker. This is both a pro (unlimited flexibility) and a massive con (development overhead).
* Observability stack is on you. We had to wire in OpenTelemetry, configure Grafana dashboards, and set up alerts ourselves. It's a significant upfront investment.

So, which is *less* painful?

I'm leaning towards a frustrating "it depends." For rapid prototyping, PoCs, or when your ecosystem is already 90% AWS, Step Functions reduces initial pain dramatically. But if you're already a Kubernetes shop running a GitOps pipeline, have the platform engineering team to support it, and **absolutely dread vendor lock-in**, the long-term pain reduction might be with OpenClaw, even with its DIY hurdles.

What's the community's take? Has anyone else run OpenClaw in production and lived to tell the tale? How do you weigh the operational burden versus the architectural freedom?