ingestlayer/blog

all posts
Post#founding

Introducing ingestlayer.

I kept rebuilding the same pattern: an event happens here, something has to happen there. So I built the universal solution I wanted.

ben5 min read


I have built the same piece of plumbing at least five times across the stack: something happens over here, and something else has to happen over there. A user signs up. A payment fails. A support ticket comes in. An error fires. And then a Slack message needs to go out, a row needs to land in the warehouse, a webhook needs to hit the CRM, an email needs to send. Every time, I wired it by hand. Every time, I told myself this was the last time.

It was never the last time. So I stopped pretending and built the thing I actually wanted. This is it.

the same problem, everywhere

The shape is always identical. An event is produced somewhere in the stack — your app, Stripe, your auth provider, a queue, a cron — and one or more things downstream need to know about it. The event almost never arrives in the shape the destination wants. It needs a field added, a name resolved, a decision made about whether it even matters.

What I ended up with, over and over, was a junk drawer. A Stripe webhook handler here. A Segment destination there. A Zapier zap nobody remembered building. A lambda that enriched one field and a cron that did the rest. Five half-systems, none of which talked to each other, all of which broke quietly and in different ways.

why the existing tools didn't fit

The marketing and lifecycle tools want you to think in sequences and campaigns. That framing is fine if you are a marketer sending a drip. It is exhausting if all you want is “when this happens, send that, there.” You end up building a multi-step flow with branches and waits to express a single rule, and then you discover it can only fan out to the two destinations the vendor happens to support.

Zapier and friends sit at the other extreme. They are general enough to do anything, which means they are overkill for the one thing, priced per task, and brittle the moment the payload changes. And for all that generality, there is still no real intelligence in the pipe. You cannot just say “read this event and tell me if it's a hot lead or spam” mid-flight without bolting on yet another step that calls yet another service. The transform stays dumb.

what I wanted instead

Three things, really. One: every pipeline should be code — a file I can read, diff in a PR, and roll back with git revert. Not a flowchart buried in someone's SaaS dashboard. Two: a classify step that is a first-class citizen, so an LLM can make a typed decision in the middle of the pipe without ceremony. Three: route the result anywhere — Slack, a webhook, the warehouse, an email, all of them at once — from the same place.

That is the whole product. Ingest the signal, transform it (enrich, classify, redact, reshape), route it to wherever it needs to go. One event in, one decision in flight, fan out on the way out.

every pipeline is a file

Here is the part I like a lot. A pipeline is YAML. The whole thing — source, steps, the model decision, the destinations and their conditions — lives in one file. It's a system and AI is notoriously great with systems. This gives the whole idea a really interesting spin, because it makes pipelines easily accessible to AI.

pipelines/signups.yaml
# pipelines/signups.yaml
pipeline: signups
source:
  type: sdk.event
  match: user.signup

steps:
  - enrich.person: $event.email
  - classify:
      input: $event + $person
      labels:
        intent: [casual, hot_lead, partner, spam]

destinations:
  - slack:
      channel: "#growth"
      when: $classify.intent == "hot_lead"
  - webhook: $env.CRM_URL
  - warehouse: events.signups

That is a complete pipeline. A signup comes in, we resolve the person behind the email, a model labels intent against a typed schema, and the event fans out three ways — but the Slack ping only fires when the intent is a hot lead. No flowchart, no campaign builder, no per-task meter. It diffs in a pull request. It reviews like code because it is code.

where this is going

ingestlayer is early, and I am building it in the open. It runs in the EU, the SDK is open source, and the pricing meters the work the pipeline actually does rather than your seats or your connectors. If you have ever wired the same A-to-B plumbing one too many times, I would genuinely like to hear how you did it and where it hurt.

Reach me at ben@ingestlayer.com. I read everything.


Read next

Redact PII from webhook events before they hit Slack.

Signup and payment notifications carry customer emails, names, and IPs into Slack. How to redact PII from webhook events, per destination, in the pipe.

← back to all posts