The feature we recoded 16 times before making it a product

Benjamin | mazaki — Wed, 22 Apr 2026 14:21:22 +0000

The activity log: the feature we've been recoding in every SaaS since 2020

Between 2020 and early 2026, we shipped 16 projects. SaaS and mobile apps combined. Some for us, some for our clients. Different verticals, different stacks, different sizes.

One thing comes up every single time.

After a few months in production, it's always the same need: we want to know who did what, and when. And we want to be notified on certain key actions. Typically on our own SaaS: successful payments, failed payments, subscription cancellations, new signups, and sometimes logins.

And every time, we start from scratch to build that piece again.

The needs that keep coming back, project after project

The pattern is always the same. At some point, on every project:

We want a real-time Discord notification on successful and failed payments
We also want to be pinged on subscription cancellations, so we can understand why and, when it makes sense, reach out to the user
We want to know the second a new signup arrives, without having to go check the dashboard
An admin needs a trace when someone touches sensitive data
A user opens a support request that requires digging into their logs to understand what happened
Each of these needs shows up sooner or later. And each one demands a layer that nobody ever lays down before actually needing it, because at launch time no one says "let's block two weeks to build a proper event system." We hack it together the first time a concrete case hits. An activity table, a webhook pushing to Discord, an internal endpoint listing the last 50 events. Until the next project where we do the whole thing all over again.

Why we kept pushing it back

Because it's never a priority. On an MVP todo list, "set up a proper audit event system" never lands in the top tier. There's payments to wire up, onboarding to polish, bugs to squash.

So we drop a console.log, we slap an INSERT INTO activity_log somewhere when we really need to track something, we add a Discord notification with a hardcoded webhook, and we tell ourselves we'll come back later to do it right (and honestly, most of the time we don't even tell ourselves that).

What it actually costs, totaled across 16 projects

The same schema debate every single time: one table per action or one big table? Free JSON or strict types? Enum of actions or free strings? We keep rediscovering the same tradeoffs and the same traps
The same Discord and Telegram notifications rebuilt by hand, with a different trigger mechanism every time
The same support tickets we can't answer properly because text logs aren't structured: it's manual grepping and a lot of guessing
The same technical debt piling up because we hack it differently on each project, with nothing ever factored out across them

The turning point, early April 2026

On our latest project, we'd built the activity log table like usual. Clean schema this time, typed actions, referenced actor, the works. But when it came to building the UI to actually use it (a dashboard to search, filter by user, export), we couldn't be bothered. We ended up plugging something together on the fly the day we needed it.

We looked back at what we'd built across the previous 15 projects. Every single time, the same promise: "we'll build the proper UI later."

That day, we realized that a feature we rebuild identically 16 times, whose UI we postpone 16 times, that we patch together with the same compromises 16 times, is not a feature we should keep coding. It's a product that should have existed already.

So we started building Recalled.

What Recalled does

Not a replacement for your observability stack. Not a compliance tool (though it works for that if you need it). Just the "action history" building block we always wanted to have ready to plug in, with the UI that comes with it.

In three lines of SDK:

import { Recalled } from "@recalled/sdk";
const recalled = new Recalled({ apiKey: process.env.RECALLED_KEY });

await recalled.events.create({
  action: "user.signup",
  actor: { id: "user_42", email: "sarah@client.com" },
});

And behind that, without coding anything else:

A structured event table, queryable by actor, action, target, date
A dashboard to browse and filter the history, the one we always pushed to "later"
An embed component to expose activity to your B2B clients directly inside your product
CSV and JSON export in one click
Discord, Telegram, and webhook notifications on the actions you choose: successful payments, failed payments, subscription cancellations, signups, logins, admin actions, whatever matters to you
Configurable retention per action pattern
Cryptographic signature on every event so no one can rewrite the history after the fact
Basically, what we wish we'd had on each of those previous projects.

The takeaway

A feature your team rebuilds identically across N different projects isn't a feature. It's a product.

If you find yourself redoing the same event table, the same export scripts, the same homemade notifications every time you ship a SaaS or an app, chances are you have the same blind spot we did.

If this resonates

Recalled is in early access. You can sign up for the waitlist at https://recalled.dev

DEV Community: Benjamin | mazaki