Building ReplayHooks: my first SaaS

I went back and forth on what would be a good project to work on. I wanted something that could potentially earn revenue, but also something people would actually find useful. We landed on a webhook tool.

The idea was not just another tool for one person to send a test request to. ReplayHooks is for people and teams that need a webhook URL they can keep, a running history of what came in, and a way to inspect and replay events when something goes wrong.

I started building around 07/28 and kept working through 08/07. You can check it out at replayhooks.com.

What ReplayHooks does

When you are working with Stripe, GitHub, Shopify, or anything else that sends webhooks, testing can get annoying fast. You need to know if the event actually fired, what the payload looked like, and whether your app handled it right.

ReplayHooks gives you a persistent URL to capture those webhooks. You can see the headers and payloads coming in live, keep the history around, replay an event after you make a fix, and share the results with your team. That was the part I felt was missing from the quick one time webhook testers.

The stack

The main app is Next.js, React, TypeScript, and Tailwind. Supabase handles the database, realtime updates, and the data side. Cloudflare handles hosting through OpenNext and Wrangler, plus R2 when larger payloads need somewhere to live.

There is Stripe for billing, PostHog for analytics, and a separate tunnel setup so the product can send webhooks back to a local app. The CLI is built in Go, the tunnel gateway runs as a Node service on Fly.io, and the CLI gets published to npm as replayhooks.

Auth with Clerk

AI recommended Clerk for auth. It was pretty straightforward to set up. The part that took a second to get used to was getting the DNS and forwarding set up right. Once that was in place, it was mostly smooth. Having email, GitHub, and Google sign in ready without building all of that from scratch was nice.

Emails, status checks, and errors

For email, we used Resend. That one was basically make an account, get it connected, and you are good to go. It handles the emails without turning into another huge thing to learn.

AI also recommended Better Stack and Sentry. Better Stack gives me status checks so I can tell if the site is up. Sentry lets me know live, right then and there, if there is an issue with the site. Since catching webhooks is the whole point of ReplayHooks, I did not want to find out something was broken after somebody else did.

The parts that gave me trouble

The hardest thing for me was the tunnel. I was not familiar with setting up a way for ReplayHooks to talk to localhost. The goal is simple: a webhook comes into ReplayHooks, then you can replay it to the app running on your own computer. Making that work meant dealing with a CLI, a tunnel server, and a few more moving parts than the normal website side.

Pushing a build to npm was another one. That was new territory too. It is one thing to get a website online. It is another thing to package a command line tool, make sure the right build gets out, and have people install it with npm. I got through it, but I definitely learned a lot doing it.

Putting it out there

I pushed ReplayHooks to Product Hunt on 08/06. It felt good to stop just building it in private and actually put it in front of people. Now I want to see what people use it for, what is missing, and what would make it better.

If you work with webhooks, give ReplayHooks a try and let me know what you think. You can leave a comment below or email me at jared@jcworkshop.com.