DEV Community: Shah

How to Track MRR and Monthly Profit per Product in Notion (Free Template)

Shah — Wed, 14 Oct 2026 13:53:38 +0000

If you run more than one product, a single revenue total hides what's actually working. One app might be paying for everything while another quietly costs you £40 a month in hosting, and the combined number looks fine either way.

This guide shows how to calculate MRR and monthly profit per product in Notion using relations, formulas and rollups. Everything here works on Notion's free plan, and every formula is copy-paste ready.

The structure

You need four databases, each linked to a central Products database:

Database	Key properties
Products	Name, Status, rollups (added in step 4)
Revenue	Date, Kind (Recurring / One-off), Gross, VAT, Fees, Product (relation)
Expenses	Date, Amount, Category, Product (relation)
Subscriptions	Cost, Billing (Monthly / Yearly), Status, Next renewal, Product (relation)

Products sits in the middle. Revenue, Expenses and Subscriptions each point at it, and Products pulls their numbers back with rollups:

Revenue        ──┐
Expenses       ──┼──► Products (MRR, revenue, costs, monthly profit)
Subscriptions  ──┘

Step 1: Create Products

One row per product, side project or client. Add a Status select with Idea, Building, Launched and Paused.

That's all for now. The useful columns come from rollups later, once the other databases exist.

Step 2: Revenue with net and MRR formulas

Create the Revenue database with Date, Kind (a select: Recurring / One-off), Gross, VAT and Fees (numbers). Add a Product relation to Products and make it two-way, so Products gets a Revenue column.

Then add these formula properties:

Net = prop("Gross") - prop("VAT") - prop("Fees")

MRR = if(prop("Kind") == "Recurring", prop("Gross") - prop("VAT"), 0)

MRR this month = if(
  formatDate(prop("Date"), "YYYY-MM") == formatDate(today(), "YYYY-MM"),
  prop("MRR"), 0)

Net this month = if(
  formatDate(prop("Date"), "YYYY-MM") == formatDate(today(), "YYYY-MM"),
  prop("Net"), 0)

A few notes on what these do:

Net is what actually lands with you: gross minus VAT minus payment or platform fees.
MRR only counts rows marked Recurring, so one-off sales don't inflate it.
The this month formulas compare the row's year-month with today's. Anything outside the current calendar month returns 0, which is what makes the rollups in step 4 show "this month" without any filtering.

Why exclude VAT from MRR? If you sell through a merchant of record such as Gumroad, Paddle or Lemon Squeezy, the VAT was never yours. Including it inflates your numbers.

Step 3: Expenses and subscriptions

These are two different kinds of cost, so keep them in two databases.

Expenses are one-off spends (a domain, an icon pack, an ad test). Add a Product relation, then a Spend this month formula using the same month comparison as in step 2, applied to Amount:

Spend this month = if(
  formatDate(prop("Date"), "YYYY-MM") == formatDate(today(), "YYYY-MM"),
  prop("Amount"), 0)

Subscriptions are the recurring tools: hosting, AI assistants, analytics, email. Add a Product relation, then normalise everything to a monthly figure:

Cost per month = if(prop("Status") == "Cancelled", 0,
  if(prop("Billing") == "Yearly", round(prop("Cost") / 12 * 100) / 100, prop("Cost")))

Yearly plans get divided by 12 (rounded to two decimals), and cancelled plans count as 0 but stay on record, so you keep the history without it skewing this month's costs.

If your subscriptions list is a mess right now, I wrote a separate walkthrough on auditing indie tool spend that covers finding every subscription and adding a renewal countdown.

Step 4: Roll it up on Products

Back on Products, add four rollups, all set to Sum:

Rollup on Products	Relation	Property
MRR	Revenue	MRR this month
Revenue this month	Revenue	Net this month
Expenses this month	Expenses	Spend this month
Tool costs / month	Subscriptions	Cost per month

Then one formula:

Monthly profit = prop("Revenue this month") - prop("Expenses this month") - prop("Tool costs / month")

Now every product row shows its own MRR, revenue, costs and profit for the current month.

Turn on the column Sum at the bottom of a table view to get business-wide totals, so you get both views: the whole business and each product.

Two views worth adding on Products:

This month: a table showing MRR, Revenue this month, Expenses this month, Tool costs / month and Monthly profit, sorted by Monthly profit.
Losing money: the same table filtered to Monthly profit less than 0. This is the one that changes decisions.

Limitations to know

This setup is genuinely useful, but be honest with yourself about what it isn't:

No currency conversion. Notion adds up numbers as entered. Pick a home currency and convert before entering; keep a Currency tag for reference.
Manual entry. Notion doesn't pull from Stripe or Gumroad natively. Log weekly, or use Zapier/Make.
"This month" is calendar-based. Annual plans paid upfront show as a spike unless you enter them as monthly instalments.
It's tracking, not accounting. Your accountant still needs proper records.

This isn't tax or accounting advice; check what your own situation needs.

Disclosure: I make Solo Founder OS, which has all of the above pre-built alongside tasks, releases and a dashboard. There's also a free Lite version covering projects, tasks and subscriptions with renewal reminders. Originally published on my blog.

7 security bugs AI agents write in Next.js + Supabase + Stripe apps (and the rules that stop them)

Shah — Wed, 14 Oct 2026 01:54:31 +0000

AI coding agents are great at getting a Next.js + Supabase + Stripe app working. They're much less reliable at getting it safe. The bugs below all pass a quick click-through test, which is exactly why they ship.

Every "fixed" snippet here is taken from a small reference app I built with Next.js 16, @supabase/ssr and the Stripe Node SDK, so you can copy them with some confidence. At the end there's a short rule you can drop into AGENTS.md / .cursor/rules for each one.

1. RLS "enabled" but a policy that protects nothing

Agents love to make an empty query go away by writing this:

-- ❌ passes the "RLS enabled" check, protects nothing
create policy "allow all" on public.subscriptions
  for select using (true);

What you want is ownership scoped to the signed-in user, and no write policy at all for tables only your server should write:

alter table public.subscriptions enable row level security;
create policy "read own subscriptions" on public.subscriptions
  for select to authenticated using ((select auth.uid()) = user_id);

Wrapping auth.uid() in (select ...) lets Postgres evaluate it once per query instead of once per row. Find existing offenders with:

select tablename, policyname from pg_policies where qual = 'true';

Rule: Every table in public has RLS enabled. Never write using (true). If a query returns no rows, fix the policy — never switch keys.

2. "Fixing" an empty result with the service-role key

The second half of bug #1. When RLS correctly returns nothing, agents often swap in the secret/service-role key, which bypasses RLS completely. Keep two clearly named clients and make the dangerous one obvious:

/** Per-request client acting as the signed-in user. RLS applies. */
export async function createUserClient() { /* createServerClient(url, PUBLISHABLE_KEY, { cookies }) */ }

/** Admin client that BYPASSES RLS. Only for trusted server code such as webhooks. */
export function createAdminClient() {
  const e = env();
  return createClient(e.NEXT_PUBLIC_SUPABASE_URL, e.SUPABASE_SECRET_KEY, {
    auth: { persistSession: false, autoRefreshToken: false },
  });
}

Put import "server-only"; at the top of that file so the build fails if a client component ever imports it.

Rule: The admin client is only used in webhook handlers and background jobs, never in code that runs on behalf of a user.

3. Trusting `getSession()` on the server

supabase.auth.getSession() reads the cookie without re-validating it with Supabase Auth. On the server, check the user properly before doing anything that matters:

const supabase = await createUserClient();
const { data: { user } } = await supabase.auth.getUser();
if (!user) return NextResponse.json({ error: "Not signed in" }, { status: 401 });

(getClaims() is also fine if you're on asymmetric JWT signing keys.)

Rule: Server-side authorization uses getUser()/getClaims(), never getSession().

4. Parsing the Stripe webhook body before verifying it

await request.json() re-serialises the payload and the signature check fails. So the agent "fixes" it by deleting the check. Read the raw text instead:

export const runtime = "nodejs";

export async function POST(request: Request) {
  const signature = request.headers.get("stripe-signature");
  if (!signature) return NextResponse.json({ error: "Missing signature" }, { status: 400 });

  // Raw body is required for signature verification. Never parse JSON first.
  const body = await request.text();
  let event: Stripe.Event;
  try {
    event = stripe().webhooks.constructEvent(body, signature, env().STRIPE_WEBHOOK_SECRET);
  } catch {
    return NextResponse.json({ error: "Invalid signature" }, { status: 400 });
  }
  // ...
}

Also exclude the webhook path from any auth middleware/proxy so it isn't redirected to a login page:

export const config = {
  matcher: ["/((?!_next/static|_next/image|favicon.ico|api/webhooks).*)"],
};

Rule: Webhook handlers read request.text() and verify the signature before touching the payload.

5. Non-idempotent webhooks

Stripe retries deliveries and can send events more than once. Record each event id with a primary key and bail on duplicates:

create table public.stripe_events (
  id text primary key,
  type text not null,
  received_at timestamptz not null default now()
);
alter table public.stripe_events enable row level security; -- no policies = no client access

const { error: dupError } = await db.from("stripe_events").insert({ id: event.id, type: event.type });
if (dupError?.code === "23505") return NextResponse.json({ received: true, duplicate: true });
if (dupError) return NextResponse.json({ error: "DB error" }, { status: 500 });

Returning 500 on a real DB error matters too: it tells Stripe to retry later instead of silently losing the event.

Rule: Every webhook is idempotent on event.id; use upsert for state.

6. Granting access from the success redirect

/account?checkout=success is just a URL — anyone can visit it. Access must come from the webhook-mirrored subscription status, and the mapping should be explicit:

export function accessFor(status: string | null | undefined): "active" | "grace" | "none" {
  switch (status) {
    case "active":
    case "trialing":
      return "active";
    case "past_due":
      return "grace";
    default:
      return "none";
  }
}

Link the Stripe customer back to your user at checkout creation (client_reference_id: user.id) so the webhook knows whose subscription it is — never take a user id or price from the request body.

Rule: Paid access is derived only from webhook-written rows. Prices come from env/server config, never from the client.

7. Open redirects in auth callbacks

Magic-link and OAuth callbacks usually accept a ?next= param. Agents pass it straight to redirect(), which turns your login into a phishing redirector (?next=//evil.com). Allow only same-origin relative paths:

export function safeNext(next: string | null | undefined, fallback = "/account"): string {
  if (!next || !next.startsWith("/") || next.startsWith("//") || next.startsWith("/\\")) return fallback;
  return next;
}

const next = safeNext(url.searchParams.get("next"));
return NextResponse.redirect(new URL(ok ? next : "/login?error=link-invalid", url.origin));

Rule: Any redirect target from user input goes through safeNext().

Bonus: fail loudly on bad env

A missing STRIPE_WEBHOOK_SECRET shouldn't become undefined at runtime. Validate lazily (so next build still works without secrets) with zod:

const schema = z.object({
  SUPABASE_SECRET_KEY: z.string().min(1),
  STRIPE_SECRET_KEY: z.string().startsWith("sk_"),
  STRIPE_WEBHOOK_SECRET: z.string().startsWith("whsec_"),
  STRIPE_PRICE_ID: z.string().startsWith("price_"),
  // ...
});
let cached: z.infer<typeof schema> | undefined;
export function env() { return (cached ??= schema.parse(process.env)); }

The takeaway

None of these are exotic. They're the predictable shortcuts an agent takes when its only goal is "make the error go away." Writing the rules down where the agent reads them every time (AGENTS.md, CLAUDE.md, .cursor/rules) fixes most of them before they're written.

Disclosure: I made these resources. I turned this into a free 30-point Supabase + Stripe pre-launch security checklist. If you'd rather have the full rule files plus the reference app these snippets come from, it's a $15 pack (25% off with DEVTO25). Either way, I hope the list above saves you a bad launch day — corrections welcome in the comments.