Matt Boone
Building
Three systems, each built because I needed it and it did not exist.
Between operating roles I do what I would do inside one: find the decisions not being made efficiently, or not being made at all, and build the system for them. These are small. The discipline and the frameworks are the parts that transfer.
01 · Relationship portfolio
Alice
A spreadsheet held my relationships and none of my decisions. Alice answers the same question every time I open it: given the outcome I am actually trying to reach, who deserves my attention next. It shows its reasoning before anything is allowed to change.
The scoring is arithmetic I can audit, run nightly inside the database, identical every time. The model only sorts information into fixed categories. Nothing reaches the record until I have approved the specific change on a card showing before, after and evidence.
Eight days from empty file to running · built and operated by one person · it replaced the spreadsheet rather than sitting beside it
Read the case study →
Alice, morning view
Already a Webflow asset on /alice. Re-point it, do not re-shoot. Names blurred, everything else live.
The ranked list: who is overdue, why, and what is owed next.
02 · M&A integration
PolarAIs
I have run integrations with no tool that tells the CFO what the end-state entity structure should be or what it costs to get there. Two organizations get fused under a clock and against a valuation, and that answer arrives in month six instead of on Day 1.
Scoring is deterministic and auditable back to the data that produced the number. The generative layer drafts and surfaces, and never writes to the record on its own. That separation is a standing design position rather than a feature still being built.
6 working prototypes · in discovery with finance and integration leaders · founder and owner
Read the case study →
PolarAIs prototype
Needs one capture, redacted. One of the six.
Entity readiness scored the same way every run.
03 · Operating business
Epic Mountain
Epic Mountain had no financial infrastructure that let anyone see what was actually happening in the business. Nothing connected what was being sold, and to whom, to the financial results that got published, or to where the next dollar of investment should go. I built that connection: revenue by segment and channel, tied to margin, inventory, memberships and labor, on a cadence the owners can act on.
The monthly review runs off that record. Every claim is typed, sourced and dated, with a prediction written down before the actuals get pulled. Nothing is deleted, only re-statused, so a claim that turned out wrong stays visible with the correction attached.
5 revenue segments · 3 claims caught, corrected or withdrawn on the record · running
Read the case study →
Knowledge ledger
Needs one capture from the Notion ledger: a claim logged, tested, and marked withdrawn with the reason attached. Figures redacted.
The shape of the catch is the point, not the number.
Why these three
The same method at three different sizes and shapes of organization.
A decision system has five parts and none of them is the software. The data has to be trustworthy and defined the same way by everyone using it. The reasoning has to be explicit, so a result can be audited instead of argued. Human guidance sits in front of the record, because judgment is the part that does not automate. Process is what makes it repeat. Accountability names who owns the decision and who lives with the outcome. All five point at the objective and at the people who have to decide.
That is the same thing I do inside a finance function. The size and the shape of the organization are the only variables.
Contact
matt@matthewboone.com
I will tell you within a day whether I am the right person, including when I am not.
Last updated September 2026