Blog

Why I built OrchVyne: 18 months of automation frustration turned into a product

A personal account of what it's actually like to be a RevOps lead who can see exactly what needs to be automated but can't build it without engineering — and what I decided to do about it.

Kevin Park, founder of OrchVyne

I spent about two and a half years as an operations lead at growing SaaS companies before I started OrchVyne. The actual work was different at each company, but the underlying problem was identical at all of them: there was a growing list of cross-system processes that everyone knew needed to be automated, and a shrinking amount of engineering bandwidth available to automate them.

I'm not writing this as a complaint about engineering teams. They had real work to do — product features, infrastructure, technical debt that actually mattered for the business. The automation backlog was a real problem, but it was the kind of problem that always got deprioritized because it was never the most urgent thing on any particular sprint. Which meant it never got done.

The thing I kept watching happen

At the third company, I started keeping a log of every manual handoff my team performed in a given week. I wanted to understand the actual scope of the problem rather than just feeling like it was large. What I found: in a single week, the two-person ops team made 47 manual data transfers between systems. Copying Opportunity data from Salesforce into NetSuite to create Sales Orders. Pasting invoice numbers into a tracking spreadsheet. Writing Slack notifications by hand after each enterprise close because the Zapier workflow we'd built had started failing on deals with multiple line items and nobody had time to fix it.

47 manual handoffs, not because my team was inefficient, but because the tools available to us didn't match the complexity of the workflows we needed. Zapier handled our simple two-step triggers fine. The multi-system, conditional workflows — the ones with branching logic, fan-out actions, and error recovery requirements — were too complex for what Zapier could handle without developer involvement, and developer involvement wasn't available.

The three-sprint backlog

I filed the ticket to fix the Zapier workflow in October. It came back as a Q1 engineering item, which meant January at the earliest. In the meantime, we had a production workflow that was failing on about 30% of enterprise deals — the ones with multiple line items — and someone on the team was manually completing those handoffs by hand each time.

I'd been through this before. At a previous role, a similar ticket sat in the backlog for three full sprint cycles — approximately 12 weeks — while the fix was a configuration change that would have taken a developer maybe 4 hours to implement. The work wasn't technically complex. The backlog was.

I started sketching out what the tool I actually needed would look like. It wasn't Zapier — Zapier's step-based linear model was the core of the problem. It wasn't Workato — Workato was priced and packaged for enterprise IT teams running iPaaS implementations, not for a two-person ops team at a growing SaaS company. It wasn't Make, which I'd tried: the branching model was better but the interface was disorienting and the error surfacing was weak enough that I spent more time debugging executions than building workflows.

What I decided to build

I wanted a workflow orchestration tool built specifically for operations practitioners — people who understand their business processes deeply and can configure conditional logic clearly, but are not software developers and shouldn't need to be. The core requirements were specific:

Native branching that ops people could understand and maintain without a Code step. Fan-out to multiple parallel actions so that a single trigger could write to NetSuite, notify Slack, create a task, and update a field simultaneously rather than sequentially. Idempotency controls so that duplicate trigger payloads didn't create duplicate downstream records. And an error audit trail that surfaced failures with enough context for an ops person to understand what went wrong without debugging code.

I also had a strong opinion about pricing. The tools that could actually handle complex workflows — Workato, Boomi, MuleSoft — were priced at $15,000 to $50,000 per year minimum. That's a reasonable investment for an enterprise IT team. It's not accessible to a three-person ops team at a 50-person company. The tool I was building was aimed at the teams falling through the gap between Zapier's simplicity ceiling and enterprise iPaaS pricing.

Building it with that constraint in mind

I started coding the first version of OrchVyne in early 2023, nights and weekends while still working my day job. The first internal prototype had the visual workflow canvas, the branching logic, and the NetSuite connector — the one I'd personally needed and couldn't get from any existing tool without enterprise pricing or a developer.

The hardest part wasn't the technical work. It was the discipline of staying focused on ops teams specifically, rather than drifting toward building a general-purpose developer automation platform. The temptation is always to add more — more connector types, more technical features, a scripting layer for power users. Every time I felt that pull, I came back to the same question: would the ops lead I used to be understand this without asking an engineer? If the answer was no, it didn't ship.

That constraint is still how we make product decisions today. OrchVyne is not trying to be the most technically powerful automation platform available. It's trying to be the one that ops practitioners can actually use at the level of complexity their workflows actually require — without the three-sprint wait.