Changelog
What we shipped.
Every entry is a piece of work that passed its tests and was ticked in our delivery ledger, newest first.
The home page, smooth and readable
The user's review of the home page: scrolling and the motion tied to it are not smooth, the hero should leave the screen with a little parallax, the six labels on the river photograph are small and say nothing, the page is slow to read, and the phone layout is poor. Measured at four times slower CPU, the page-height river caused 98 frames over 33 ms in one scroll of the page: its mask and its always-running dash and radius animations repaint a layer as tall as the page on every frame.
Launch on D1 alone
The first production launch runs on one database, the D1 binding `DB`. The Postgres cell (a Hyperdrive binding, the `/api/search` route that read it, its launch steps and its dependencies) is removed: no screen called the route, and the user chose D1 alone for launch.
The river site, faster and drawn further
Plan 066 redrew the site as one river. This plan keeps that direction and raises it: the home page loads fast on a phone, the two platform areas that only had app captures get drawn diagrams of their own, and the inner pages are brought up to the home page.
The marketing site, redrawn as one river
One river now runs down every page of the site: aerial photographs and film of real rivers, the real app captured from the live demo, and a drawn river that carries a referral from its first click to the payout. No section is a grid of boxes.
A live demo anyone can open
A visitor clicks "Try the demo" and lands in their own program full of partners, customers, commissions and payouts.
The app and the portal in motion
Every change of state in the app and the portal moves with one shared set of motion tokens, and stays still for anyone who asks for less motion.
A help center for every screen, every event and every endpoint
The docs answer how to do each thing in the app and the portal, and describe the API from its OpenAPI document.
Learn: guides on running a SaaS partner program
Original, practical guides a founder reads before and after launching a partner program.
The marketing site, redesigned with motion and every page a buyer looks for
An original design at the level of the best SaaS sites in the category: one token set, one motion system, and a page for every question a buyer asks before signing up.
Test mode for every program
Merchants try their integration with their billing provider's test mode and see the result in the app, without touching live numbers.
A test environment and runnable walks
A deployed staging copy of the app and site on their own database, and browser walks anyone can run against it or against a local dev server.
Payouts settle on their own
Every payout ends paid or failed without anyone watching: a lost webhook is recovered, a failure reaches the partner, and both sides see what is owed and when.
Trust pages, changelog and our own affiliate program
The marketing site answers a buyer's checks, and Affiligato sells through itself. From the Tolt gap matrix (research/gaps.md, items 53, 54).
Paddle Classic, Shopify app billing and warehouse export
More places a merchant's revenue comes from, and their data where they analyse it. From the Tolt gap matrix (research/gaps.md, items 42, 43, 50).
Refer-a-friend reward types
Customers referring customers, paid in credit instead of cash. From the Tolt gap matrix (research/gaps.md, item 41).
OpenAPI spec and an npm tracking package
Developers integrate without reading source. From the Tolt gap matrix (research/gaps.md, item 40).
Portal account features
Partners manage their own account. From the Tolt gap matrix (research/gaps.md, item 39).
Customer journey and live visitors
What happened to one customer, and who is arriving now. From the Tolt gap matrix (research/gaps.md, item 37).
Payouts across programs and a payout calendar
One payout day for a merchant with several programs. From the Tolt gap matrix (research/gaps.md, item 36).
Rule extras: proration, product caps, templates, duplicate
The commission recipes merchants reach for most. From the Tolt gap matrix (research/gaps.md, item 35).
Partner languages for emails and the portal
Partners read their emails and portal in their own language. From the Tolt gap matrix (research/gaps.md, item 31).
Program coupons and codes on every provider
Discounts partners can hand out, and code attribution beyond Stripe. From the Tolt gap matrix (research/gaps.md, item 28).
Security, developer tooling and resources depth
The platform around the product: safer sign-in, tools for developers, richer resources. From the Tolt gap matrix (research/gaps.md, 2026-11-03).
Partner profiles, import and portal depth
Richer partners, migrations without loss, and a portal partners live in. From the Tolt gap matrix (research/gaps.md, 2026-11-03).
Billing extras and integration logs
Fewer missed sales and a way to see what every integration sent. From the Tolt gap matrix (research/gaps.md, 2026-11-03).
Email automations, scheduled campaigns and portal announcements
Talking to partners on a schedule and inside their portal. From the Tolt gap matrix (research/gaps.md, 2026-11-03).
Commission boosts and bulk commission tools
Limited-time offers for partners, and fixing commissions in bulk. From the Tolt gap matrix (research/gaps.md, 2026-11-03).
API and webhooks completeness
Everything the app does, reachable from the merchant's own server. From the Tolt gap matrix (research/gaps.md, 2026-11-03).
Payout operations and terms
Payout day as merchants actually run it. From the Tolt gap matrix (research/gaps.md, 2026-11-03).
Attribution controls and lead review
The merchant decides who gets credit and for how long. From the Tolt gap matrix (research/gaps.md, 2026-11-03).
Email templates and the missing emails
Every email a program sends, editable, testable and switchable. From the Tolt gap matrix (research/gaps.md, 2026-11-03).
Click enrichment and report breakdowns
Where clicks come from and what they turn into, by place, device, source and link, every month. From the Tolt gap matrix (research/gaps.md, 2026-11-03).
Automatic fraud rules
Fraud stopped as it happens, not only flagged afterwards. From the Tolt gap matrix (research/gaps.md, 2026-11-03).
Rules engine depth
Rules that express what real programs pay: grouped conditions, more facts to match, more actions. From the Tolt gap matrix (research/gaps.md, 2026-11-03).
Groups with their own doors
A group is more than a rate: its own sign-up link, description, approval, privacy and payout minimum. From the Tolt gap matrix (research/gaps.md, 2026-11-03).
Customer lifecycle
Customers carry a status the merchant and partner can read, kept current from subscription events. From the Tolt gap matrix (research/gaps.md, 2026-11-03).
Transactions as records
Every payment and refund a billing provider reports, kept as its own record, so merchants can see, fix and rebuild commissions. From the Tolt gap matrix (research/gaps.md, 2026-11-03).
Polish
`src/lib/i18n.test.ts` (every key in every language, placeholders kept), `src/lib/theme.test.ts`, the commissioned-only test in `worker/portal/portal.test.ts`, and the browser walks against `pnpm dev` (a de-DE, dark-scheme partner context; a dark merchant overview).
Embeds, widget and MCP
`worker/embed/embed.test.ts` (through the real entry point, so the frame headers are the deployed ones; the widget script run in a stub DOM) and `worker/mcp/mcp.test.ts` against a local D1, plus the merchant walk rendering the embed inside an iframe.
More integrations
`worker/integrations/integrations.test.ts` against a local D1, built from RevenueCat's webhook docs as fetched on 2026-11-02 (auth header, revenue event types, CUSTOMER_SUPPORT refunds, sandbox, zero-decimal currencies, subscriber attributes).
Tracking extras
`worker/tracking/extras.test.ts` against a local D1 (leads, postback macros and once-only calls, the snippet run in a stub browser for each foreign parameter, CSV import with skips), `src/lib/qr.test.ts`, and both browser walks (import, QR).
Engagement
`worker/engage/engage.test.ts` with the mailer and an in-memory R2 captured (segments, once-only sends, the 14-day window, Monday summary, signed downloads and a forged one), and both browser walks.
Payout breadth
`worker/payouts/*.test.ts` against a local D1: the Airwallex cross-currency body (source_amount, checked against the transfer spec in the provider research), invoices on both the manual and managed paid paths (mutation-checked), and the 1099-NEC export.
Outgoing webhooks and public API
`worker/webhooks/webhooks.test.ts` with a fake network against a local D1 (signatures, subscriptions, backoff schedule to failure, retry, REST API with paging and key scoping), the site build, and the merchant browser walk.
Team and audit log
`worker/team/team.test.ts` against a local D1 (seats, roles, the audit middleware with redaction), `src/lib/audit.test.ts`, and the merchant browser walk (invite a teammate, read the log).
Partner lifecycle
`worker/partners/lifecycle.test.ts`, `worker/portal/*.test.ts` and `worker/tracking` against a local D1, plus the merchant and partner browser walks.
Commission rules engine
`worker/rules/*.test.ts` (pure engine, and the procedures with creditSale/refundSale against a local D1), the Stripe, Paddle, Chargebee and API rule tests, `src/lib/rules.test.ts`, and the merchant browser walk (rule, preview, partner override).
Custom domains
A merchant's partner portal at their own address, and partner emails from their own domain.
UI overhaul
An original, dense, professional design system, and every page rebuilt on it.
Managed payouts
The merchant pays one invoice per payout cycle; the platform then pays every eligible partner by PayPal, Wise or bank transfer. Money movement goes through licensed providers (PayPal Payouts, Wise Business), never through code that holds funds itself.
Billing integrations
Merchants bill through Stripe, Paddle or Chargebee, or something else entirely. Every source ends up in one sale and refund core, so partners are credited the same way whatever the provider.
Marketing site
The public site at the apex domain, with an original design.
SaaS billing
How the platform charges merchants: Starter $29, Growth $69 and Pro $129 a month, priced on referred revenue like the incumbent's $99 and $199 plans but well under them, with a 14-day trial and plan limits.
Partner portal
The partner's side, branded with the program's colour, logo and copy: `/portal/:slug` (landing and join), `/portal/:slug/dashboard`, `/links`, `/referrals`, `/commissions`, `/payouts` and `/settings`.
Merchant app
The merchant's side of the app, with a sidebar and a program switcher: `/p/:id` (overview), `/p/:id/partners`, `/p/:id/partners/:partnerId`, `/p/:id/referrals`, `/p/:id/commissions`, `/p/:id/payouts`, `/p/:id/links`, `/p/:id/promo-codes`, `/p/:id/groups`, `/p/:id/settings/{general,portal,payouts,notifications,integrations}`, `/billing` and `/new`.
Settings and notifications
`worker/settings/*.test.ts` and `worker/notify/*.test.ts`, with the mailer captured.
Links and promo codes
`worker/links/*.test.ts`, `worker/tracking/*.test.ts` and `worker/conversions/*.test.ts` against a local D1.
Partner management
`worker/partners/*.test.ts` against a local D1.
Analytics
`worker/analytics/*.test.ts` against a local D1.
Data model v2
What the full product needs on top of the MVP tables: the revenue behind each commission, partner groups with their own terms, extra links, Stripe promotion codes, portal branding, partner payout methods, notes, and the program's integration heartbeat.
Pricing and landing
The site build succeeds, and its test asserts that the plans render.
Dashboard UI
`pnpm --filter @affiligato/app build` succeeds, the lint gates pass, and a Playwright walk over `vite dev` reaches each page.
Affiliate portal API
`worker/portal/*.test.ts` against a local D1.
Merchant API
`worker/merchant/*.test.ts` calls the tRPC router with a caller context against a local D1.
Commission lifecycle
`worker/lifecycle/*.test.ts` against a local D1.
Stripe conversions
The merchant points a Stripe webhook at `/api/hooks/stripe?program=<id>`, signed with a secret stored on the program.
Referral tracking
The public, unauthenticated surface that a merchant's website and the affiliate's links reach.
Affiliate store
The D1 tables and the queries over them: programs, affiliates, clicks, referrals, commissions, payouts and the merchant-event inbox. Every query is scoped to a program, and a program to its owner.
Affiliate domain
The pure rules of an affiliate program, with no I/O: referral codes, commission amounts, the attribution window, commission states and payout grouping.