This is a fascinating model, thanks for sharing. The classic "engineering as the bottleneck" problem is something every product engineer feels, so I deeply appreciate the desire to solve it.

I'm intrigued by this API-first approach, and it's left me with a few questions from my perspective as an engineer who builds product features:

How do you handle features with complex UI/UX? While a push notification is a perfect fit, how would a non-eng person build, say, a new analytics dashboard with interactive charts or a multi-step modal view? Is there a clear line where a feature's complexity means it has to go back to the engineering team?

Who owns the holistic user experience? With different people building features decentrally, how do you ensure the product feels cohesive and not just a collection of disconnected Zapier flows? I imagine maintaining a consistent design system and user journey could be a challenge.

You mentioned the "duct-tape logic" problem. This is the part that resonates—and worries—me most. Do you have a formal process for refactoring or "graduating" a successful duct-tape solution into a core, robust, engineer-built API? How do you manage that accumulating technical debt?

As an engineer, the idea of focusing solely on clean, scalable APIs is incredibly appealing. At the same time, there's a certain joy in crafting and shipping a polished feature directly to users. It's a really interesting trade-off you've presented.

Thanks again for the thought-provoking post.