I spent 6 years as the founding engineer at a programmatic video generation company. This was before AI video. We were doing conventional compositing at scale, at a price point that's still below what AI-generated video costs today.
The hardest part was never the video rendering. It was the orchestration.
Every video job was a dynamic workflow. Different assets, different templates, different downstream services, all changing constantly. And none of the services involved should've needed to understand the bigger picture. A rendering service should just render. A transcoding service should just transcode. Each one operating in isolation, focused on its core intent, with no knowledge of the ecosystem around it.
The real problem was bringing them together. How do you compose independent services into workflows that change as fast as the business needs them to, without redeploying anything?
I never solved that problem the way I wanted to. Tools like Zapier and Make existed, but they weren't built for developers. They were built for non-technical users connecting apps through a UI. You couldn't version control a workflow, you couldn't programmatically create one, and the execution model was "hope the server stays up." n8n was closer to developer-friendly, but still no real durability, no SDK, and no way to treat workflows as code alongside everything else in your stack.
The founder and I had a falling out after 6 years and I left the company. But the problem stuck with me. I'd spent years watching the same pattern: services that worked perfectly in isolation, but the glue between them was fragile, tightly coupled, and required a deploy every time the workflow changed.
---
WHY NOW!
With serverless architecture, the pieces finally exist to do this right. You can deploy services rapidly (Cloud Run, MCPs, whatever) and they just work as HTTP endpoints. The missing piece was always the orchestration layer. Something that could compose these services dynamically, with real durability, without deploying new code every time a workflow changes.
---
WHY NOT N8N!
I know people will ask "why not n8n?" Honestly, I didn't come at this from the no-code automation world. I came at it from Temporal. The starting point was durable execution, not connecting apps. The visual builder came later because I realized not everything needs to be code. But the foundation is Temporal's execution model, not a traditional automation tool with reliability bolted on after the fact. They overlap on the surface (both have a canvas, both wire up API calls) but they're built from opposite ends.
So I built it. Being a bit of a completionist (and admittedly a weirdo), I figured I'd see this model all the way through.
---
TEMPORAL.IO
Why Temporal matters here. The core insight is that workflows need to survive failures. Not "retry from the beginning," but actually pick up where they left off. Temporal gives you event-sourced execution, replay on crash, and per-item isolation.
In practice that means forEach batches run each item as its own Temporal child workflow, item 500 fails and the other 9,999 keep going, retry just that one. AI agents (ADK agent nodes) run as durable Temporal workflows, so state persists across turns and you can do human-in-the-loop approval before the agent does anything dangerous. And if you already run Temporal Cloud, you can plug in your own namespace and Graph Compose uses it (BYOK).
---
OPEN SOURCE
What's open source. Open-core. Core types, schemas, graph validation, and a runtime that executes HTTP DAG workflows on your own Temporal (the @graph-compose/runtime package) are AGPL-3.0. The integrations service is open too (graph-compose/nodes). You can read exactly how the execution model works, run basic workflows on your own infrastructure, and contribute integrations. The kernel is designed to be extensible beyond HTTP, the node execution contract is generic, so adding new invocation types (gRPC, message queues, custom protocols) is a matter of implementing a handler, not rearchitecting the engine.
The platform orchestrator (error boundaries, forEach child workflows, ADK agents, streaming execution), the visual builder, the API layer, and the AI assistant are proprietary. I'm bootstrapping this, and giving away the entire product to compete on hosting margins isn't viable. I'd rather be upfront about that boundary than pretend everything is open and surprise people later.
---
CURRENT LIMITS
What it doesn't do yet. The integration catalog is smaller than n8n's 400+ connectors, but the nodes service is open source and structured so anyone can add one, standardized REST endpoint with Zod validation and auto-generated OpenAPI specs, PRs welcome. The open-source runtime is deliberately limited: HTTP-only DAGs, no persistence, no agents. It's the real execution model, not a demo, but the advanced orchestration features are platform-only. And the visual builder is functional, not beautiful, I don't have a design team.
The stack. Next.js (App Router) for UI and API routes, Supabase for auth/data, Temporal for orchestration, Cloud Run for workers (TypeScript and Python for ADK agents), GCP Secret Manager, Stripe for billing. Deployed on Vercel, Cloud Run, and Cloudflare.
---
QUESTIONS
Two honest questions for the HN crowd.
1) The workflow orchestration space is crowded, n8n, Make, Zapier, Windmill, Inngest, Trigger.dev, Step Functions. My bet is that Temporal changes the conversation: the execution model is fundamentally better for anything where reliability matters, and most of these tools don't have it. Is that a strong enough differentiator to build a business on, or am I underestimating how little most users care about durability?
2) I'm thinking about how to grow this into a viable long-term platform without classic VC scaling. Referral-based equity for people who drive real adoption, contributor equity pools, revenue share for community members who build integrations. If you've scaled a developer tools company, experimented with non-traditional growth models, or have opinions on open-core go-to-market, I'd love to hear it.
I spent 6 years as the founding engineer at a programmatic video generation company. This was before AI video. We were doing conventional compositing at scale, at a price point that's still below what AI-generated video costs today.
The hardest part was never the video rendering. It was the orchestration.
Every video job was a dynamic workflow. Different assets, different templates, different downstream services, all changing constantly. And none of the services involved should've needed to understand the bigger picture. A rendering service should just render. A transcoding service should just transcode. Each one operating in isolation, focused on its core intent, with no knowledge of the ecosystem around it.
The real problem was bringing them together. How do you compose independent services into workflows that change as fast as the business needs them to, without redeploying anything?
I never solved that problem the way I wanted to. Tools like Zapier and Make existed, but they weren't built for developers. They were built for non-technical users connecting apps through a UI. You couldn't version control a workflow, you couldn't programmatically create one, and the execution model was "hope the server stays up." n8n was closer to developer-friendly, but still no real durability, no SDK, and no way to treat workflows as code alongside everything else in your stack.
The founder and I had a falling out after 6 years and I left the company. But the problem stuck with me. I'd spent years watching the same pattern: services that worked perfectly in isolation, but the glue between them was fragile, tightly coupled, and required a deploy every time the workflow changed.
---
WHY NOW!
With serverless architecture, the pieces finally exist to do this right. You can deploy services rapidly (Cloud Run, MCPs, whatever) and they just work as HTTP endpoints. The missing piece was always the orchestration layer. Something that could compose these services dynamically, with real durability, without deploying new code every time a workflow changes.
---
WHY NOT N8N!
I know people will ask "why not n8n?" Honestly, I didn't come at this from the no-code automation world. I came at it from Temporal. The starting point was durable execution, not connecting apps. The visual builder came later because I realized not everything needs to be code. But the foundation is Temporal's execution model, not a traditional automation tool with reliability bolted on after the fact. They overlap on the surface (both have a canvas, both wire up API calls) but they're built from opposite ends.
So I built it. Being a bit of a completionist (and admittedly a weirdo), I figured I'd see this model all the way through.
---
TEMPORAL.IO
Why Temporal matters here. The core insight is that workflows need to survive failures. Not "retry from the beginning," but actually pick up where they left off. Temporal gives you event-sourced execution, replay on crash, and per-item isolation.
In practice that means forEach batches run each item as its own Temporal child workflow, item 500 fails and the other 9,999 keep going, retry just that one. AI agents (ADK agent nodes) run as durable Temporal workflows, so state persists across turns and you can do human-in-the-loop approval before the agent does anything dangerous. And if you already run Temporal Cloud, you can plug in your own namespace and Graph Compose uses it (BYOK).
---
OPEN SOURCE
What's open source. Open-core. Core types, schemas, graph validation, and a runtime that executes HTTP DAG workflows on your own Temporal (the @graph-compose/runtime package) are AGPL-3.0. The integrations service is open too (graph-compose/nodes). You can read exactly how the execution model works, run basic workflows on your own infrastructure, and contribute integrations. The kernel is designed to be extensible beyond HTTP, the node execution contract is generic, so adding new invocation types (gRPC, message queues, custom protocols) is a matter of implementing a handler, not rearchitecting the engine.
The platform orchestrator (error boundaries, forEach child workflows, ADK agents, streaming execution), the visual builder, the API layer, and the AI assistant are proprietary. I'm bootstrapping this, and giving away the entire product to compete on hosting margins isn't viable. I'd rather be upfront about that boundary than pretend everything is open and surprise people later.
---
CURRENT LIMITS
What it doesn't do yet. The integration catalog is smaller than n8n's 400+ connectors, but the nodes service is open source and structured so anyone can add one, standardized REST endpoint with Zod validation and auto-generated OpenAPI specs, PRs welcome. The open-source runtime is deliberately limited: HTTP-only DAGs, no persistence, no agents. It's the real execution model, not a demo, but the advanced orchestration features are platform-only. And the visual builder is functional, not beautiful, I don't have a design team.
The stack. Next.js (App Router) for UI and API routes, Supabase for auth/data, Temporal for orchestration, Cloud Run for workers (TypeScript and Python for ADK agents), GCP Secret Manager, Stripe for billing. Deployed on Vercel, Cloud Run, and Cloudflare.
---
QUESTIONS
Two honest questions for the HN crowd.
1) The workflow orchestration space is crowded, n8n, Make, Zapier, Windmill, Inngest, Trigger.dev, Step Functions. My bet is that Temporal changes the conversation: the execution model is fundamentally better for anything where reliability matters, and most of these tools don't have it. Is that a strong enough differentiator to build a business on, or am I underestimating how little most users care about durability?
2) I'm thinking about how to grow this into a viable long-term platform without classic VC scaling. Referral-based equity for people who drive real adoption, contributor equity pools, revenue share for community members who build integrations. If you've scaled a developer tools company, experimented with non-traditional growth models, or have opinions on open-core go-to-market, I'd love to hear it.