Pifr was born inside a Notion. Here is why it left.
A spreadsheet first, then five linked Notion databases with the layout and the automations that come with them. The system ran for real and it paid real people. Here is what it brought, and the five places it eventually stalled.
Can you track commissions in Notion?
Yes, and for months we did nothing else. The system ran on five linked databases: members with their rates, deals, instalments, payouts, and the organization's settings. Commissions were computed through relations and rollups, the cascade worked, and a manager did receive their percentage of their team's collected cash.
It was not a sketch. It was the product, and it paid real people. By the time we left, we had roughly the structure Pifr has today: one shared dashboard, and a page per person. What stopped holding was not the structure. It was what the structure cost to keep alive.
Where Pifr comes from, in order
A spreadsheet first, like everyone, and not for long. It is free, immediate, and it accepts any splitting rule you can type into a cell. But the moment more than one person opens it, it turns messy: permissions stop at the whole file, one mistyped cell shifts a total, and nothing warns anyone. We wrote separately about how to build it properly, and where it breaks.
Then Notion, for structure. That was the goal and it worked: a readable layout, relations that spared us retyping the same names everywhere, and a few automations, notably when a new client came in. The system became presentable, which matters when a whole team looks at it every day.
Then the limits, five of them. They did not arrive on the same day, but all five arrived. None could be fixed inside Notion, because none came from a bad setup: they came from what a page-based tool is. That is where the idea of writing real software came from, instead of working around it forever.
What Notion does very well
This needs saying, because it is true and because we chose it. Notion accepts a new structure in minutes: one more database, a relation, a rollup, and the numbers flow up. For prototyping a commission system it is hard to beat, and that is exactly what it gave us.
It is also readable, far above a spreadsheet on that count. A tidy Notion database can be shown to a rep without embarrassment, which a twenty-column file never allows. If your need stops there, stay.
Where Notion eventually stalled
The five points below are not objections of principle. They are the ones we ran into, in the order they appeared, while running real commissions for real people.
For a rep to see their numbers, you have to open the database
This is the main wall, and it is structural. Notion shares pages, not rows depending on who is looking. For a number to appear on a setter's private page, they need access to the data behind it. Setter or owner, everyone ends up in front of the same interfaces. You work around it by putting people in read-only and hiding three quarters of the properties, but that protects the display, not the data: the whole database stays one click away.
Everything is typed in by hand
Once the row existed, commissions did flow, all the way into personal spaces. But the row had to be written: every deal, every instalment, every payment, one at a time. A payment received in Stripe ticks no box in Notion. On the days nobody opens the database, a rep's numbers are wrong, and they are the first to notice.
The calculation has no memory
A rate lives on the member's record. Change it and every past calculation changes with it, including months already paid. What you need is the rate frozen at the moment of the deal, so the past stays what it was. No Notion formula does that unless you copy the rate by hand onto every row, which brings you back to the previous point.
It buckles as volume grows
Two reps and five deals a month, Notion holds effortlessly. Thirty deals paid in instalments, a setter on 7 %, a closer on 10 % and a manager on 3 % of their team's cash, and the number of relations to keep current grows far faster than the team. That is the moment the system starts feeling scary to edit.
The time it costs eventually shows
This is the wall nobody talks about and the one that actually makes you leave. For a rep, Notion stays pleasant. For a sales manager, an administrator or an owner, every month end becomes an evening of typing, checking and reconciling. A tool that takes an evening a month to say who earned what costs more than it saves.
The same system, from both sides
| Notion | Pifr | |
|---|---|---|
| What a rep sees | The whole database, or nothing | Their numbers, plus team totals |
| A rep's rate | Lives on their record, and rewrites the past when changed | Frozen on each deal, the past stays stable |
| What releases a commission | A box ticked by hand | Cash collected, confirmed by Stripe or Whop |
| A deal outside Stripe and Whop | A row to write, then its instalments | One form, and the split follows |
| Deleted relation | The total changes silently | History stays, nothing disappears |
| What is still owed | Another database to maintain | A balance per person, computed |
| Setup | Five databases to build and maintain | An organization, members, rates |
What we chose to do differently
Pifr first existed to keep what Notion had given us. The rest answers the five walls above, point by point.
Everyone sees only what concerns them
A read-only guest opens the team dashboard and stops there. A setter sees the team target, their ranking, and their own numbers in a space nobody else reads. An administrator is the only one who can enter data. This is not a hidden view, it is the database refusing to answer.
Collection ticks itself
Stripe and Whop are connected: a confirmed payment triggers the split between closer, setter and manager, each at their own rate, instantly. A deal that comes from neither is logged by hand, in one gesture, and leaves the same trail.
The past stops moving
The rate applied is frozen at the moment of the deal. Raising a rep changes what they earn tomorrow, never what they earned last month. That protects them as much as it protects the organization.
Competition is visible
Top closer, top setter, progress toward the period target. It is the part teams open most often, and the part a raw table of numbers never gives you.
Built by salespeople, for salespeople
Pifr was not imagined at a whiteboard. It was built by people whose job is selling, for a commission-only team that had to pay its closers and setters every month and was tired of spending month end copying rows.
It shows in details you only find if you have been on both sides. An earned commission stays earned, even if the client is refunded later: the rep did the work, the business carries the risk. A rep keeps their profile and their history when they change teams, because their track record belongs to them. And nobody can rewrite a number after the fact, which protects the organization as much as the rep.
Once the old tables were moved into Pifr, the product grew beyond what the Notion could have carried: full organization management, an agency mode for those running several teams, and a marketplace where verified organizations publish their offers. The thread never changed: make it smooth, make it simple, and make it take as little time as possible.
The product keeps moving on feedback from both camps: the organizations who pay, and the reps who get paid. When both ask for the same thing, it is usually the right thing.
When to stay on Notion
If your team fits in one room, everyone can see everyone else's numbers without it causing a problem, and you collect in one payment, Notion will do the job. The first wall to fall is almost always permissions: the day a rep needs to see their own numbers without seeing everyone else's.
Frequently asked questions
Can you run sales commissions in Notion?
Yes, and we did for months across five linked databases. Notion holds as long as everyone is allowed to see everything and the volume stays small. The wall arrives when a rep needs to see their own numbers without seeing everyone else's.
Can Notion hide certain rows from certain people?
No. Notion permissions apply to pages and databases, not to rows depending on who is looking. For a number to appear on a rep's private page, they need access to the database holding the whole team's numbers.
Why not create one Notion database per rep?
Because you trade a permissions problem for a synchronisation problem. Each database becomes a copy that drifts, and team totals stop being calculable without stitching everything back by hand.
Why leave Notion if the system worked?
Because it cost too much time to keep alive. Commissions flowed once the row existed, but every deal, every instalment and every payment had to be typed in by hand. As volume grows, month end turns into an evening of data entry for the administrator.
What does Pifr do that Notion cannot?
Four things: separate data per person, freeze a rep's rate at the moment of the deal so a rate change never rewrites the past, release commissions on cash collected rather than on signature, and connect Stripe or Whop so that collection ticks itself.
Who built Pifr?
People who sell. The product came out of a commission-only sales team's own need, was prototyped in Notion before it was written, and keeps moving on feedback from both sides, the organizations who pay and the reps who get paid.