One execution layer to replace the ETL, reverse-ETL and automation stack

A data team of any size ends up paying for three products that overlap: a managed ETL tool to pull data in, a reverse-ETL tool to push it back out, and an automation platform to glue the edges together. Each has its own connectors, its own credentials, its own idea of what a schedule is, and none of them can see the others. The integration surface is the product nobody bought.

Partic was scoped as the argument that this should be one layer, and that the layer should be an API rather than a scheduler.

What we did

A managed team, accountable for a working runtime rather than a feature list.

1. Scoping, four days. One decision governed everything else: bidirectional by default. If every connected system is both a source and a destination, the connector model, the credential model and the execution model all change shape. Deciding it in week one avoided rewriting all three later.
2. Factory setup, week one. Environments, CI, and a conformance suite every connector has to pass before it exists.
3. Build, weeks two to thirteen. Four certified engineers, shipping weekly. The engineers owned the continuous execution runtime, change data capture, and the audit trail that makes private deployment defensible. Agents generated connectors against the conformance suite, which is what made a fifteen-connector launch surface realistic on this timeline.
4. Hardening and handover, weeks fourteen to sixteen. Compliance-grade audit trails, private deployment path, load testing against sustained event throughput, documentation.

What made the difference

The conformance suite came before the connectors. Once a connector is defined as anything that passes a fixed set of behavioural tests, generating one is a tractable problem and reviewing one is a fast problem. That is the whole reason the connector count is not the schedule.

AI Nexus, which generates connectors and pipelines from a chat instruction, is the same mechanism turned outward: what our engineers used to build the platform became a feature customers use to extend it.

Where it landed

Pipelines run as live APIs rather than scheduled jobs, with change data capture, native transformation, and real-time event and request-triggered execution. First live pipeline takes about five minutes.