VAMOS: One Button, Two Hundred Emails

Every quarter, my firm reconciles compensation for its advisors: what came in, who serviced it, and whether everyone’s numbers hold up. For years that process lived in a huge, complicated spreadsheet. And it ended with a macro that opened two hundred-plus emails so the finance team could send each advisor their summary, individually, by hand.

This quarter it ended with one button. VAMOS generated every advisor’s PDF summary and sent every email in a single press.

The button is the flashy part. It’s also the least interesting part. The real work was everything that made the finance team comfortable pressing it.

What VAMOS is

VAMOS is the firm’s internal advisor platform. I inherited it as a prototype and had about a month to get it calculating compensation in production, on a hard deadline. It shipped, and it’s kept shipping ever since. This year it took over the entire quarterly reconciliation: the system produces draft reports, advisors get a review window to report corrections, and finals go out once the numbers survive scrutiny. Q2 2026 was the first quarter run end to end on the system.

I own the whole thing, from the PostgreSQL database to the React frontend to the pipeline that deploys it, and the requirements come straight from the people who run the firm.

Advisors got a page, not just a report

Advisors had their own version of the spreadsheet problem. The old quarterly report told them everything they needed, but it was a PDF that showed up once a quarter, after the fact. In between, plenty of advisors kept their own trackers: which invoices had been paid, what they expected to make, how things were trending.

So the advisor side of VAMOS is a webpage, not a document. Their main page shows a breakdown of their practice, where their compensation comes from, and the same numbers the quarterly report will contain, live: what everything would say if the quarter closed today, checkable on any day they’re curious. Being a page instead of a PDF also made room for things the report never had, like historical trends and outstanding invoices. When you can check your current status whenever you want, the shadow spreadsheets lose their reason to exist.

The official quarterly report is still a PDF, and its content is nearly identical to the old one, on purpose. What changed is that it stopped being the only window into the numbers. That ordering is no accident, either: the live page was the original prototype I inherited. The quarterly report is the part that got bolted on.

Trust is the actual product

The goal on the finance side was never speed. It was confidence. Surface problems as early as possible, and make the team certain that what goes out is accurate.

So the process is built to catch problems before anyone outside the team sees them. VAMOS runs the quarter’s data through layers of validation checks, and everything it flags lands on a list for the finance team to review. Each flag is marked either info or warn: info means a scenario we know can legitimately happen and just want a human to look at, warn means something that shouldn’t be possible. The finance team clears that whole list before a single PDF is generated.

The reports themselves go out in two passes. Drafts first, with a window for advisors to flag anything that looks wrong. Then finals. And nothing is official until Quarter Close locks the numbers in.

None of this makes for an exciting demo. All of it is why the button gets pressed without anyone holding their breath.

Modular, because the process belongs to finance

Quarter close isn’t a hardcoded pipeline. It’s a set of backend functions and frontend components that I can slot together in whatever order the finance team wants the process to run. If they want a new check between two existing steps, that’s a slot, not a redesign.

That flexibility got tested immediately. Q2 was our first live quarter, and I was making changes mid-cycle based on the finance team’s feedback, including building entirely new review sections for things they wanted to verify that I hadn’t thought to show them. There’s no better trust-builder than asking for a new safeguard on Monday and reviewing your data in it that week.

The comp model is data, not code

The other decision that keeps paying off: the comp model isn’t in the code. At all. The rules for how invoice amounts get split, the numbers behind each advisor’s compensation structure, and the transition rules as someone advances in their career are all rows in the database, each with a start and end date. When an advisor moves from one compensation structure to the next, the system blends the transition so their total never goes down. That blend is also just dated rows.

A change to the comp model is a database update with an effective date, not a code deploy. History also comes free: because every rule carries its dates, the system can tell you exactly what the rules were in any given quarter. For a reconciliation system, that’s not a nice-to-have.

Where it stands

The name stands for Valeo Advisory Model Operating System, and the operating-system part is the ambition: the long-term goal is for VAMOS to be the main software the firm runs on. It’s already growing beyond compensation into other corners of the firm’s data. Q2 proved out the quarterly cycle. The validation layers caught what they were supposed to catch, the finance team pressed the button, and two hundred emails sent themselves. The next few quarters are for sanding down what Q2 taught us, and for finding the next spreadsheet to retire.