Founded in 2018. Still independently built and run.

I'm Carlos, the engineer behind Posthook. I started it in 2018 after running into a problem that sounded simple but kept turning into custom infrastructure: scheduling something to happen later, reliably, for a specific user or event.

At the time, I was building a social events product that needed scheduled reminders. I couldn't find anything focused on that one job without dragging in a broader workflow system or a pile of glue code. So I built Posthook.

Before and alongside Posthook, I've spent fifteen years as a backend engineer at companies of all sizes, building production systems where reliability mattered. Posthook reflects that bias: simple primitives, clear boundaries, and infrastructure that stays boring when your product depends on it.

Today, Posthook is still actively maintained and run by the same person who started it.

How this works in practice

• Direct email. support@posthook.io goes straight to me.
• No handoffs. The person answering questions is the person who wrote the system.
• Fixes ship fast when they need to. There isn't a layer between support and engineering.
• Support is thoughtful and personal. You're talking to the builder, not a queue.

What that means for reliability

Posthook is monitored around the clock. I get paged for the kinds of issues that point to platform health problems: delivery failures across customers, pipeline backups, API instability, or infrastructure behaving outside normal bounds.

There is also external monitoring outside the core stack. If the scheduling API stops responding, a synthetic delivery test fails, or the dashboard goes down, I know about it quickly through a separate path.

The goal is simple: when your app depends on something happening later, Posthook should quietly do its job.

What you're paying for

Posthook is self-funded and intentionally focused. You're not paying for a sales team, a layered support org, or a product trying to be everything. You're paying for dependable scheduling infrastructure, clear product judgment, and direct access to the person responsible for the system.

That tradeoff has been the shape of the company since the beginning, and it's how I plan to keep operating.

What Posthook is, and isn't

Posthook is intentionally narrow. It is not a full workflow orchestration system or a general background job platform.

It's for the cases where your app needs something to happen later, at the right time, reliably. That focus is why it exists, and why people use it.

If that's the problem you have, Posthook is built for it.