Hi DEV community,
I'm Yuriy, a fullstack developer and DevOps engineer with 10+ years of experience. I'm currently building Adal — a webhook delivery and observability platform for developers.
The idea came from a simple frustration: webhook delivery often feels like a black box.
A provider sends a request. Something fails. Maybe the endpoint was down, maybe the payload was different than expected, maybe the retry happened later, maybe the logs are incomplete. As developers, we often end up guessing instead of debugging from clear facts.
Adal is my attempt to make webhook delivery more predictable.
The core principles are simple:
- permanent endpoint URLs;
- full request visibility;
- delivery logs that explain what happened;
- replay without waiting for the provider;
- retries that are visible and controlled;
- no hidden transformations;
- infrastructure that can be inspected and reasoned about.
I'm building Adal as a practical developer tool, but also as an engineering experiment: how much of webhook infrastructure can be made explicit, observable, and boring in a good way?
The stack is mostly Go, PostgreSQL, Redis, React, Docker, Cloudflare R2, and a regional architecture for receiving and delivering webhook requests. The CLI is open source and written in Go.
On this DEV organization page, I plan to write about the technical side of building Adal: webhook infrastructure, backend reliability, regional delivery, observability, product decisions, failures, trade-offs, and lessons from building a SaaS from scratch.
This is still an early-stage project, but it is already public and usable.
If you work with webhooks, build integrations, or care about predictable backend systems, I'd be happy to hear your feedback.
Top comments (0)