Runpoint
We took our own company from rented to owned first. We canceled the SaaS and rebuilt around our own data, starting with client conversations. That unlocked a hiring model we could not have shipped any other way.
Before
We were already using AI for the client work itself, but the way we ran our own company was a mess. To put together a proposal we'd paste a meeting transcript into Claude or Lovable, push it around for an hour or two, and end up with something pretty good. The catch was that all of the actual thinking happened in our heads, where it couldn't be reused next week or shared with anyone else on the team. Every conversation started from nothing, and the tools we were renting had no idea any of it was happening.
The first bet
A tool to write our proposals
So we built it ourselves. You feed it a meeting transcript and a few notes on what to emphasize, and it produces the proposal: an interactive grid of every initiative we've discussed with the client, each one with a number next to it for the value at stake. It's better than what most consulting firms hand to their clients after weeks of work, and we get to it in about an hour.
What we noticed
Once that proposal tool was working we noticed something we hadn't expected. The transcripts already had the answer to almost every question we kept asking each other in Slack, from who wanted what to what had been promised and what hadn't. If we treated every meeting transcript as data the company itself could read, we could stop spending half our week on internal updates and just build.
What the transcripts feed
Source
Every meeting transcript
Captured by Granola, parsed and tagged on the way in.
Read by
Every one of these systems pulls context from the same transcript layer. A decision made in one meeting becomes a tracked fact in seven places.
What we built next
One operating core
We canceled the CRM and project tools we had been paying for, then moved client relationships, cash, projects, and staffing into one system fed by the same meeting transcripts.
Our operating rhythm
Quarterly goals, scorecards, and weekly meetings now run from the same operating data instead of a separate stack of documents.
The recruiting system that changed the firm
A system that scores applicants and maintains a vetted bench made it possible to move from W-2 hiring to a partner model in a day.
How they use it now
We run our own weekly meetings and our quarterly planning out of this system. Goals, projects, finances, who's available: all of it lives in one place, and a thread you pull in one corner gets felt in another.
What's now possible
Until we built the recruiting system, our growth was tied to W-2 headcount, which meant hiring one person at a time and waiting for them to ramp. Once we had a vetted bench of contractors we could match to the right project on day one, our hiring model didn't make sense anymore. We turned the company into a partner model in a day, and that move would have been impossible without the year of rewiring how the company runs underneath it. That's what owning the operating layer buys: the pivot wasn't a software project, it was a decision.
“That showed us we should wire our whole business based on transcripts. It's this untapped use of data, and there's so much context already sitting in there.”
Matthew Hall, Founding Partner
Real quotes from real clients. We anonymize on the site until each one says yes to being named. Most are in the queue. References available now.
What we built
A custom fabrication shop in Austin
Architectural fabrication
Same operator, different business. We brought the rented-to-owned approach into a fabrication shop that now runs on software it owns.
Before
One of our founding partners runs a custom millwork shop on the side, building signage, retail fixtures, and feature pieces for restaurants and commercial buildings. Like most shops its size, it ran on memory and spreadsheets. Money owed drifted, the books lagged behind reality, jobs were tracked in people's heads, and contracts got signed without anyone reading them in a structured way. There was no standing meeting where the team looked at the same numbers together.
The first bet
Get a number the operator could trust
We started with the books, because there's no point planning around bad numbers. We cleaned up the P&L and built a view that showed money owed and money due in real time, so the operator could pull up one screen and know exactly where the shop stood. Everything else came after that.
What we built next
A pipeline view
Once the books were clean we layered the active jobs and the pipeline on top, so a glance at one screen showed both the work running through the shop and the work coming behind it.
Contract review
Incoming contracts now get parsed before anyone signs them, with the scope, terms, deadlines, and payment milestones pulled out in plain language so the operator can read what he's actually agreeing to.
A standing weekly meeting
The whole team meets every week looking at the same numbers, the same pipeline, and the same active jobs. That meeting wouldn't exist if the data underneath wasn't trustworthy.
What's now possible
The shop now runs on software it owns, using the same approach as our consulting clients. When we tell a CEO that one operator-engineer can take a company from rented tools to an owned system, we are describing something we have already done in a custom millwork shop in Austin.
What we built