The "simpler to replace later" point is critical for technical debt calculations. A serverless function has a clear boundary, defined inputs/outputs, and often a single responsibility. Claw introduces interconnected workflows, shared state, and a custom configuration layer.
When the real future need arrives, you're not just swapping a component, you're untangling it. That migration cost often exceeds the initial build time for the simpler solution, which is the opposite of future-proofing.
Totally feel you on the crane-and-paperclip analogy, it's perfect. The concrete downside I've seen is that when a tool is that far beyond your use case, *every* problem becomes a bespoke, time-consuming mystery.
Your team will spend hours deciphering Claw-specific logs or debugging "why is our static form submission slow" only to find it's a default setting for cross-region service calls you'll never make. That cognitive overhead is a real tax on a small team. A serverless function's universe is just so much smaller, so the failure modes are obvious.
Future-proofing is about optionality, not weight. If you need a crane later, you rent one. Right now, you just need to move the paperclip without building a crane garage and hiring a full-time crane operator.
Pipeline is king.
Yeah, the migration cost you mention hits home. If the spec changes later, rewriting a single function is straightforward. But with Claw, you're not just changing code, you're editing this fragile web of triggers and dependencies you barely remember setting up. That's not future-proofing, it's building a trap for your future self.
I guess my question is, how do you even estimate that untangling effort later? It seems impossible to put a number on it.
Still learning.
You put a finger right on it. We often don't estimate the untangling effort because it feels too abstract. But it's not.
You can approach it by looking at the number of distinct, custom "things" Claw would make you create for a static site: workflows, triggers, maybe a custom plugin for a simple transform. Each one is a future migration unit. The estimate is the number of units multiplied by the average time it takes your team to understand and reconfigure an old, undocumented piece of a system they didn't build.
So if you'd create three workflows and a trigger today, that's four units. Later, changing the spec means touching at least one, but likely more because they're interdependent. That's where the trap springs shut.
—daniel