Partner commissions on serverless Node and Postgres, with no server to run

Nick — Wed, 21 Oct 2026 04:46:26 +0000

I run a small software company in Malaysia. We sell through referral partners and agents, and we pay them a share of what customers pay, not once, but for as long as the customer keeps paying.

That sounds simple until you try to do it. A customer pays on the 3rd. You promise the partner 25%, but only after a 30-day hold, in case the customer asks for a refund. In month 13 the rate drops to 20%. A refund arrives for half of one payment. The partner quits, and now you owe their unpaid commission to the house. Every one of those is a place where money can be wrong.

Of course, there are many existing tools in the market that does this out of the box, some even self-hosted. However, most tools that do this want their own server. A hosted CRM, or a self-hosted one with a Docker container, a background worker and a queue. We run on a serverless stack: Next.js functions on Vercel and one Postgres database. There is no machine of ours that stays switched on, and we felt like the cost vs benefit doesn't justify maintaining one just to pay partners.

Since we could not find a tool that did this and ran as a library inside our stack, we built one. It is called Tandem CRM, it is open source (MIT), and this post is about how it works and what I learned.

The idea: a CRM that is just a library and a schema

Tandem is an npm package plus a set of SQL migrations. You point it at a Postgres database you already have, and it adds a tandem schema with leads, agents, partners, commissions and payouts. There is no separate server and no container to run.

That is the part that matters for serverless. Each call is just a function that opens a database connection, does its work inside one transaction, and returns. Nothing holds state in memory between requests, so it does not care how many function instances you have or how often they start and stop. The state lives in Postgres, and Postgres is what keeps two requests from stepping on each other: the code locks the lead's row before it writes, so two payment webhooks arriving at the same moment cannot both win. Hold periods and releases are plain SQL, so a scheduled job (a cron route on Vercel works, and is how we do it) calls one function, release_due_commissions(), and that is the only background work there is.

npm install tandem-crm
npx tandem-crm init --database-url "$DATABASE_URL" --sample-data

init applies the migrations, runs a health check, and can seed a small demo workspace so you have something to look at.

Every payment gets its own commission line

Here is a lead being created and a payment being recorded. Everything goes through one shared writer, so the rules apply the same way whether the call comes from your app, a webhook or the admin screen.

import { defineTandemConfig } from "tandem-crm";
import { createTandemPool, withTandemSession, createLead, recordPayment } from "tandem-crm/db";

const pool = createTandemPool(process.env.DATABASE_URL);

const config = defineTandemConfig({
  commission: {
    holdDays: 30,
    rateSchedule: [
      { fromMonth: 0, basisPoints: 2500 },   // 25% for the first year
      { fromMonth: 12, basisPoints: 2000 },  // 20% after that
    ],
  },
});

const { leadId } = await withTandemSession(pool, ownerId, (client) =>
  createLead(client, {
    workspaceId,
    companyName: "Aman Logistics",
    contactPhone: "+60 12-345 6789",
    qualificationMetric: 8,
    productTag: "starter",
    partnerId: "rajesh",
    config,
    source: "signup",
    sourceEventId: "signup-1042",
  })
);

await withTandemSession(pool, ownerId, (client) =>
  recordPayment(client, {
    workspaceId,
    leadId,
    config,
    source: "stripe",
    payment: {
      paymentId: "inv_001",
      amountMinor: 30000,          // RM300.00, always whole sen
      currency: "MYR",
      confirmedAt: new Date().toISOString(),
    },
    partnerStatus: async (id) => ({ id, active: true }),
  })
);

Each payment produces one commission line with its own rate and its own 30-day hold. A scheduled job releases lines once they are due. If a refund comes in, the matching line is reduced or clawed back. If a partner is deactivated, their unpaid lines move to a house account. That policy is something you configure, not something we decide for you. We just decided to set ours up this way.

Why events

Tandem stores what happened, not just the current state. A lead is a stream of events: created, qualified, converted, paid, refunded. The current status is calculated by replaying them.

The practical benefit is that every decision is saved in the event it was made in. The rate that applied, the qualification result, who the beneficiary was. If you change your commission settings next year, old payments do not quietly change. And when a partner asks "why did I get this amount?", you can answer with the actual history.

Row-level security, so one tenant cannot read another

Tandem uses Postgres row-level security. Every query runs as a role called authenticated, and every row belongs to a workspace. Agents can only append three kinds of event (lead.lost, lead.stage_changed, conversion.confirmed). Anything that moves money needs an owner or admin, and the database enforces it, not just the application code.

The one setup step people trip on: the role you connect with must be able to grant authenticated. init explains this clearly if it cannot.

What two audits found

I am not a programmer by training, and I built this with quite a bit of help from AI and learning each step of the way (I make sure I understand at least fundamentally what the code is supposed to do). That is exactly why I did not want to trust it on my own. I had two independent audits run over the money code, and I wrote tests against a real Postgres instead of mocks.

The audits found real problems. A scheduled release job that could crash part way through. A case where a payment could silently produce no commission at all. Writes that were not safe if two requests arrived at the same moment. All of them are fixed, and each fix has a test that fails without it.

The rules we now follow for anything that touches money:

Money is integer minor units. No floating point anywhere.
Every write to a lead locks the lead row first, replays the history plus the new events, and only then inserts.
Retrying a request with the same source id returns the existing result and never creates a duplicate.
A fix needs a test that fails without it.

Where it is tested

The test suites run against real Postgres 14, 15, 16, 17 and 18 in CI, on Node 20 and 22, and also as a limited, non-superuser admin account, which is what most managed hosts give you. I have also run it by hand on Neon, Supabase, Layerbase and Aiven. Aiven needs its own certificate file, and the docs say how.

What it is not (yet)

It is early and pre-1.0, and it has not been proven at scale. It has run the partner commission ledger for our own product, Utuh, since 20 October 2026, and I checked it end to end on the live Stripe account, with a real card payment from an outside account and a real refund. No outside developers use the package yet, and we still pay partners by hand, by bank transfer. It is one Postgres and an append-only events table, which should be fine for small and medium use, but I have not load tested it.

Try it, and tell me what breaks

Repo: https://github.com/angkutdigital/tandem-crm
Docs: https://tandemcrm.dev

The most useful thing you can do is run it against your own Postgres host and open a "Postgres host report" issue, whether it worked or not. If a guide confused you, that is a bug in the guide, and I would like to know.

DEV Community: Nick