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. It ended with a macro that opened more than two hundred emails so the finance team could send each advisor their summary, individually, by hand.

In Q2 2026, 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 is also the least interesting part. The real work was everything that made the finance team comfortable pressing it.

From visual prototype to production system

VAMOS began as an ambitious AI-generated frontend filled with dummy data. It imagined a future platform spanning several of the firm’s core systems and made that vision tangible enough for people to react to.

But there was no production system underneath the screens.

About a month before our annual company meeting, we committed to turning one part of that vision into a real application: Practice Management. Advisors would be able to see the clients they served, understand how their income was changing, and compare the composition of their practice with others at the firm.

The scope had to become much smaller and the engineering effort much larger.

I served as the technical lead and domain expert on the original two-person build. As a former advisor, I understood both what people wanted to see and the financial rules behind it. I led the data model, compensation engine, warehouse integration, infrastructure, CI/CD, and performance work.

My colleague led much of the Microsoft identity implementation and the work of connecting the inherited frontend to real APIs while removing its dummy data.

Together we built the system behind the interface: a PostgreSQL database, a Python backend, Microsoft SSO, role-based authorization, data synchronization from the firm’s warehouse, automated tests, deployment pipelines, and the environments required to run it.

Before launch, I load-tested the system around the heaviest usage pattern we expected: most of the firm signing in at once during the annual meeting.

VAMOS debuted at that meeting through a recorded walkthrough. The firm received the production URL, and people began exploring it afterward. The simultaneous traffic spike never materialized, but the application was live, running on real data, and ready for it.

The first version ran on virtual machines. As the platform matured, we moved it to Azure Container Apps with containerized deployments, managed secrets, and CI/CD carrying changes through the environments.

That initial month produced one bounded, production-ready slice of a much larger idea. It has kept growing ever since.

Advisors got a page, not just a report

Advisors had their own version of the spreadsheet problem.

The old quarterly report told them what they needed to know, but it was a PDF that arrived once a quarter, after the fact. In between reports, plenty of advisors kept their own trackers: which invoices had been paid, what they expected to make, and how their practice was trending.

VAMOS made that information live.

An advisor’s main page shows the composition of their practice, where their compensation comes from, outstanding invoices, and historical trends. Most importantly, it shows the numbers that would appear if the quarter closed today. Advisors no longer have to wait for the official report to understand where they stand.

When people can check the current system whenever they want, the shadow spreadsheets lose their reason to exist.

The official quarterly report is still a PDF, and its contents remain deliberately familiar. What changed is that the report stopped being the only window into the numbers.

That ordering is no accident. The live Practice Management page was the first production feature. The quarterly reconciliation came later, built on the same data and calculation engine.

Trust is the actual product

The goal on the finance side was never speed. It was confidence.

The system needed to surface problems early and make the finance team certain that what went out was accurate.

VAMOS runs the quarter’s data through layers of validation checks. Everything it flags lands in a review queue for the finance team. Some flags represent situations that can legitimately happen but deserve a human look. Others identify conditions that should not be possible. The team clears that list before a single PDF is generated.

Reports then go out in two passes. Advisors receive drafts first and have an opportunity to report anything that looks wrong. Finals follow only after that review period. Nothing becomes 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 is not a hardcoded pipeline. It is composed from backend functions and frontend sections that can be arranged around the process the finance team actually wants to follow.

If the team wants a new validation step between two existing stages, that is a new slot in the workflow, not a redesign of the system.

That flexibility was tested immediately.

Q2 2026 was our first live quarter, and I was making changes during the cycle based on what the finance team learned while using it. That included building new review sections for information they wanted to verify but that I had not originally thought to show them.

There is no better trust-builder than asking for a new safeguard on Monday and reviewing your data in it that week.

The process belongs to finance. The software is designed to adapt around it.

The model is data. The engine applies it.

VAMOS has a calculation engine, but the firm’s compensation model is not hardcoded into it.

The formulas, values, and effective dates that define the model live in the database as configuration data. When the engine runs, it selects the configuration that applies to the quarter and applies it to the incoming financial records.

That boundary is deliberate. A change to the compensation model becomes an effective-dated data change, not a code deployment. The engine changes only when the way VAMOS interprets or applies that configuration needs to change.

Because prior configurations retain their effective dates, the system can reconstruct the model that applied during any quarter. Historical compensation remains tied to the rules in effect at the time rather than being reinterpreted under today’s configuration.

For a reconciliation system, that separation between software and business policy is essential.

Owning the whole platform

VAMOS is not just the application code.

I remain responsible for the system from its data model through production: the PostgreSQL database, backend services, React frontend, warehouse synchronization, cloud infrastructure, deployment pipelines, performance, and the engineering process used to change it safely.

The team has remained small, with additional contributors taking ownership of individual features. That makes technical boundaries and shared standards especially important. Automated tests run on every pull request, deployments move through controlled environments, and CARL gives every change an automated review before a human code owner approves it.

The requirements come directly from the people who operate the firm. My job is to translate those requirements into a platform that remains coherent as each new feature arrives.

That translation is where most of the work is.

Where it stands

VAMOS stands for Valeo Advisory Model Operating System. The operating-system part is the ambition: the long-term goal is for VAMOS to become the primary software through which the firm understands and operates itself.

The annual meeting proved that we could turn a visual concept into a live production application on a hard deadline.

Q2 proved that the same platform could carry an entire quarterly reconciliation from live advisor data through validation, drafts, corrections, final reports, and distribution.

The validation layers caught what they were supposed to catch. The finance team cleared the review process. Someone pressed the button.

And two hundred emails sent themselves.