Every financial event in your company should be a queryable, time-traveled row in your own warehouse, on your own machine. Not in Ramp's cloud. Not in Bill.com's database. Not in some vendor's tenant. Yours.
That is the bet this entire plan is built on. The next generation of finance buyers will not accept the SaaS deal where they ship their vendor list, contracts, and payment history to a third party in exchange for a workflow. Cloud finance software is a 2010s artifact. The AI era will not look like more of it.
The buyer we are building for
A company of five to fifty people, run by a founder who still reads the chart of accounts. No full-time CFO. Big enough to feel the seams between Stripe, the bank, QuickBooks, and Notion. Small enough that putting the books in Ramp or Bill feels like giving up something they want back later. This is the segment we win in year one. Ramp owns 50-to-500. Bill owns above. QuickBooks owns sole proprietors. We own the founder-run middle.
The trigger is a Tuesday afternoon. The founder is closing Series A diligence, or answering a board question about runway, or pricing a renewal. The answer requires opening four dashboards and one spreadsheet, and the numbers don't reconcile. That is the moment they go looking for something else.
What we believe that the incumbents don't
The strong financial tools of the 2010s are cloud SaaS by design. The AI runs on the vendor's servers because that is where your data already lives. The product is the cloud. We think that arrangement stops working for two reasons.
The buyer changes. A 5-to-50-person company in 2026 is paranoid in roughly this order: losing customer trust, losing payroll runway, losing the right to take their own data with them when they leave. Putting the books in Ramp or Bill kills the third one. Switching costs a migration. Acquisition costs a renegotiation. An audit costs an export of their own data from someone else's server.
The AI changes. Local 70B-class models running on M-series hardware already match cloud frontier models on the narrow tasks that make up finance work: invoice extraction, AP coding, reconciliation reasoning, and dunning copy. By 2028 we expect local models to lead on those four. The finance corpus is small, the document formats are bounded, and the cost of fine-tuning a domain-specific model collapses faster than the cost of frontier compute grows. Once that flip happens, shipping your invoices to OpenAI is no longer the path of least resistance. It is the path of inherited habit.
Local-first is not a feature on one of our products. It is the architecture every step below is organized around. If a layer of this plan cannot be shipped local-first, we won't ship it.
1 · Sync.
A local data plane. It mirrors every financial event in your company into a Postgres warehouse you control: Stripe charges, bank transactions, QuickBooks entries, contracts, customer threads. Time-traveled. Queryable. Joinable to whatever else the operator already has.
Sync is the wedge. We sell it first. Once an operator has their own financial records in a warehouse they own, every cloud product they pay for starts to look strange. Why is the source of truth in Ramp's tenant? Why does QuickBooks own my chart of accounts? Sync makes those questions feel obvious. Steps 2 through 5 are how we answer them.
Here is the year-one demo. A founder installs Sync. Within a few minutes, every Stripe charge from the last three years, every transaction across Mercury and Brex, every invoice in QuickBooks, every contract in Notion is mirrored to a Postgres database on their laptop. They open a chat window and ask, “what did our AR aging look like on March 15 of last year, by customer cohort?” Sync answers in two seconds, joined across the four sources, with citations the founder can click through to the underlying records. Their current stack cannot answer that question without four CSV exports and a spreadsheet. That is the moment they decide.
OperatorCamp ships alongside Sync as the field manual for operators running it without a team. Playbooks, templates, and field notes for the parts of the work the AI doesn't do.
2 · Eigenn on Sync.
The financial operations console. Cash forecasts, scenario models, collections, reconciliation. Every card on the operating board is a real financial object: an overdue invoice, a reconciliation exception, a renewal coming up in sixty days. Move a card to Paid and the actual payment happens through Cadense. Eigenn's AI reads from your Sync warehouse, not from our database. Nothing the operator looks at is data we have access to.
Local-first finance was a real category once. Beancount, Hledger, desktop Quicken were all built on the assumption that the books belong on the operator's machine. SaaS killed it because the AI of the 2010s needed cloud scale to be useful. The constraint that killed it has lifted. Eigenn is not inventing a category. It is restoring one with the AI that finally works on a laptop.
3 · Cadense on Sync.
Accounts payable end-to-end. Invoice capture, approval routing, scheduled payouts through licensed payment partners. Same architecture as Eigenn. The bills and the bank statements stay in your warehouse. Cadense is a client of Sync, not its owner.
4 · Conduitt on Sync.
The customer-communications layer. Every invoice thread, every reply, every event on a single timeline that reads from your own data. The customer's history lives in your warehouse, not on a vendor's helpdesk. Conduitt closes the loop between the books and the conversations.
5 · Open Sync as a platform.
Once Eigenn, Cadense, and Conduitt are stable on Sync, open Sync to outside builders. Schemas, webhooks, identity, workflow primitives. Other companies run their revenue operations on the same data plane.
Sync is the only place a third-party builder can ship a finance product that the customer trusts because the data never leaves the customer's machine. Stripe gives a builder the transactions, but the customer's books are still hostage to whoever's cloud the rest of the stack runs on. Sync is where that changes. This is where Solomon AI stops being a suite of finance apps and starts being the substrate other people build on.
That is where Part One ends and the bigger arc begins.
The 20-year horizon
The same architectural bet plays out in three larger acts. These don't happen in sequence. All three are starting now in primitive forms (Stripe's ACP, the early agent layers at Mercury and Brex, stablecoin B2B pilots) and mature in parallel through the 2030s and 2040s. The architectural bet is what puts Sync at the center of each one as it matures. Each one needs Sync to be universal and to stay local-first.
6 · Years 5 to 10. The AI CFO runs on the operator's machine.
Every founder-run small business has an AI agent running its finance function. The agent runs on the operator's machine, reads from their Sync warehouse, and never ships books to a cloud LLM. It drafts invoices, schedules payments, runs dunning, files taxes. A short list of decisions that need the owner's attention shows up each Monday.
The cloud AI CFOs that Ramp and Mercury launch in 2027 are the natural extension of their architecture: a smarter dashboard with their data still on the inside. Ours is the opposite shape. By 2031 we expect that to be the difference that decides the segment.
7 · Years 10 to 15. Agent-to-agent commerce on verifiable books.
Each side of a B2B transaction has an agent. Invoice negotiation, payment terms, dispute resolution all collapse from email and calls into handshakes that close in seconds.
The agent on each side has to be able to make verifiable claims about its own company without exposing the underlying data. Sync ships with a primitive for selective disclosure: your agent can prove the last 90 days of AR exceed a threshold without revealing the underlying invoices. The signed claim travels over the wire; the data stays on the machine. Cloud-finance vendors can't play this game. Their customers' agents can't trust a counterparty whose books live in a competitor's tenant.
8 · Years 15 to 20. Programmable money meets a local ledger.
Tokenized cash, conditional payouts, on-chain settlement collapse the gap between contract and clearing to milliseconds. The companies that win this era are the ones that own the link between operational data and financial primitives.
Programmable money is only as useful as the data the contract can read. A conditional payout that releases when an invoice is thirty days overdue has to reference the AP queue, the dispute log, and the customer thread. If your AP queue lives behind Bill.com's API and your customer thread lives behind a helpdesk vendor, your smart contract cannot compose them. The data has to be in one place the contract can reach, and that place has to be yours. That is the argument for a local ledger underneath programmable money, and it is the argument Sync's platform was designed to make.
By the end of this period, “finance software” means a personal financial operating system: your own warehouse, your own agent runtime, your own ledger, your own UIs running on top. The reconciliation work disappears because the data is shared by default between your apps, your agents, and the people you do business with.
What would prove us wrong
By 2030, if the highest-NPS finance tool among 5-to-50-person companies is still a SaaS-cloud product where the company's books live on the vendor's servers, the local-first bet was wrong. We are betting that does not happen.
By 2035, if “accounts payable software” is still a category buyers shop for as a separate product, instead of a capability inside an agent that reads from a local warehouse, we were also wrong about the shape of this.
By 2032, if cloud-hosted finance LLMs running on customer data still outperform local agents reading from a local warehouse on a published benchmark of daily finance work, the AI half of the bet was wrong. The buyer-side argument (data ownership matters) could still hold without the AI-side argument (the work runs locally), but the master plan would need to be rewritten with that in mind.
Where the bet has attack surface
Five honest risks. The first one matters more than the rest combined.
The cloud has more data than we do. Ramp's AI sees AP coding across thirty thousand companies; a local Sync agent sees one. If smarter always beats more private, we lose. That has been the revealed preference for fifteen years across Gmail, Maps, Photos, Docs, and every other category where users could have chosen local-first and didn't.
The bet is that finance is the category where it flips. Most of the daily work is company-specific. An agent reading three years of your own operational data outperforms one averaging patterns across thirty thousand strangers on the decisions that run your books day to day. It knows your chart of accounts, your vendor list, the customers who chronically pay late, the edge cases in your billing. Cross-customer signal helps with cold start. It doesn't dominate day-to-day work.
For the slice where cross-customer signal does help (vendor name disambiguation, generic AP priors, anomaly detection), Sync ships an opt-in federated learning channel. A customer can choose to contribute model gradients to a shared training run. The gradients leave the machine. The underlying invoices, contracts, and bank statements stay on it. We publish differential- privacy bounds on what an attacker could recover from the gradients we contribute. The promise that your raw books stay on your machine holds, with one caveat: gradients encode some information about the books, and the customer chooses whether to participate.
The addressable buyer in year one is narrower than the addressable market. The 5-to-50 founder-run segment is large. The subset that buys local-first finance in year one is smaller. Three buyer profiles dominate the wedge: technical founders who already run their own Postgres, founders in regulated industries, and founders who already got burned by a vendor lock-in. That comes to twenty to forty thousand companies globally, not two hundred thousand. The wedge expands from there if any of three triggers fires: a public breach at a cloud finance vendor, an AI auto-pilot scandal that pushes buyers toward locally controlled agents, or enough product polish to pull the broader founder-run middle along on its own.
The pricing model is structurally smaller than Ramp's. There is no interchange rake to take on payments that flow through licensed partners. There is no easy way to meter AI consumption when the inference runs locally. Pricing is per-seat across the products, plus managed-Sync infrastructure for customers who'd rather not self-host. The SaaS pricing model of 2010, not the compounding take-rate that built Ramp into a $13B company. Sync could be a great product and a structurally smaller business. We are building for the defensible shape first and earning the right to the bigger one.
The platform play takes longer than the four products do. Step 5 opens Sync to third-party builders, but the trust argument only works at scale, and the user base reaches that scale only after the four products have been in the market for a few years. A third-party builder picks Stripe over Sync until Sync has addressable users. The trust premium is what flips that calculation. Step 5 starts in year six or seven, not the moment Conduitt ships. We are saying that here so the timing reads honestly.
Programmable money is upside, not foundation. Step 8 depends on smart contracts being a meaningful interface for finance operations, on programmable money clearing real B2B flows, and on the local ledger being where those contracts compose. Any of those could fail to materialize without breaking the rest of the plan. We are not betting the company on step 8. It is an upside the architecture makes available.
The hardest of these is the first. If the operator's local agent and Ramp's cloud agent disagree on what to do, and Ramp's has seen thirty thousand other companies' patterns, the operator will ask why they're paying us for the dumber agent. Our answer is that the operator's own history matters more than the cross-company average for company-specific finance work, and that the federated channel covers the rest without putting the raw books on someone else's server. The day that answer stops being true is the day this business hits a wall.
Where we are now
Sync is in production. Eigenn and Cadense ship on it daily. Conduitt is live with first design partners. OperatorCamp publishes the playbooks for operators doing this work without a team.
We are saying all of this now so that nothing we do on the early steps forecloses on the rest.
Solomon AI
This is Part One. Part Two will be written when the horizon section above stops being a forecast and starts being a checklist. Read why we're doing itfirst if you haven't.