We Told You to Own Your Operating System. Here's Ours.

CRAFT OS was built to run client engagements. It runs ours now too, and the first proof of that is the most boring workflow we have: how our own team requests time off.

The test we don't usually apply to ourselves

Every article I've published this year makes some version of the same argument. Own your coordination layer, don't rent it. A vendor that owns the layer your business runs on holds the leverage, and you find that out at the worst possible time, not the best one. I said it most directly three weeks ago: the businesses that win the next three years are the ones that treat that layer as the thing worth owning, while everyone else is still shopping for tools.

It's a fine argument. It's also an easy one to make from the outside. I make it to clients every week. I argued back in June that CRAFT runs a business, not just software delivery, and that argument has been sitting there mostly as a claim. This is where it stops being one.

InTech runs on CRAFT OS. Same operating system logic we install for clients, same methodology, held to the same standard we hold theirs to. I'm not going to walk you through the whole thing today. Some of what's underneath it is exactly the kind of reusable architecture I'm planning to open up properly in the pieces ahead. What I want to show you now is smaller, and I think more convincing than a diagram would be: the moment our own back office broke in a way I recognized immediately, because I've diagnosed the same break in a dozen client businesses, and what we did about it.

Nobody on our team announced this as a strategic initiative. There was no steering committee, no slide with a roadmap on it. There was just a week where the PTO tool we'd been renting for years stopped being a minor annoyance and started being a real cost, someone doing manual reconciliation work that a system should have been doing for them, and finally me asking the question I ask clients constantly: why are we tolerating this.

The tool that broke

For a while, InTech ran PTO and time tracking on a rented tool, the same category of point solution I tell clients to stop stacking. It did one thing, adequately, and it didn't talk to anything else. It didn't know our accrual rules across a team split between our Tampa Bay office and our Panama operations, so someone reconciled that by hand every pay cycle. That's the eleven-tools problem I wrote about in June, wearing an HR costume instead of a customer service one. Same failure mode. Different department.

I had already written the diagnostic for this exact thing. I had not run it on us.

That's the part worth being honest about. It's easy to sell a business-versus-build framework to a client staring at a shelf of disconnected SaaS tools. It's a different thing entirely to notice you're standing inside your own case study. Nobody on the outside was pointing at us and laughing. I didn't need them to. Once I saw it, I saw it everywhere: the same pattern I've written up for a boutique wealth management firm and a field service company, present in our own operations the whole time, just quieter, because it's easier to spot a mess in someone else's business than to admit you're standing in one.

In "Foundation or Build" back in June, I laid out the question that actually decides this, and it isn't "what do you want to buy." It's where your business is actually breaking. Ours was breaking at the seam every operator recognizes and nobody wants to deal with: the unglamorous system of record that HR and finance both depend on and neither owns cleanly.

I ran our own diagnostic and didn't love being on the other side of it. The honest answer was build, not buy, for the same reason it's the honest answer for the clients I hand this framework to. A rented tool would always be a point solution bolted onto the outside of how we work. We needed something that held context, not another login, and no amount of switching to a different vendor's version of the same category was going to fix that. The problem was never which PTO app. The problem was that PTO lived outside the system that already knew everything else about how our team operates.

So we built one. On CRAFT OS. In about two days.

The two-day build

Two days isn't a heroics story, and if it were, it'd be a bad argument for owning your own operating system, because heroics don't scale and they don't repeat. Two days is what happens when the scaffolding already exists.

We didn't start from a blank repository. CRAFT OS already held the context layer I described in April, the same Context Graph pattern that primes Claude with institutional knowledge instead of making it guess at how our business actually runs. Before a line of the new module got written, Chuck's team wrote down the intent the same way I described in our second article back in April: what this system was actually for, what it was allowed to decide on its own, and what had to route to a person. That's not paperwork for its own sake. It's the same Decision Record discipline from the piece we published right after it, capturing what got decided and why instead of letting an agent quietly make the call and hoping it was the right one.

Then there was the gate. CRAFT OS already had one modeled on the Fortify Gate discipline I wrote about in May, the checklist that turns "done" from a vibe check into a question with a real answer, and it mattered here more than in most modules we've shipped. A PTO system that miscounts someone's balance isn't a cosmetic bug. It's a paycheck-adjacent one, and it needed to be right before anyone touched it, not eventually right after a support ticket.

Building the new module looked exactly like building one for a client: write the intent down before writing anything else, hold the context in one place, let an agent propose the mechanism, gate what matters, ship it, then watch what actually happens once real people depend on it. The speed didn't come from skipping steps. It came from most of the steps already being paved by every module built before it. That part isn't mine to take credit for. It's Chuck and the team's discipline more than mine, but it's the same discipline I've been describing all year, and now I've watched it work on us instead of just a client.

The detail I actually want you to notice

Here's the detail worth sitting with, because it's the whole argument in miniature. The module that replaced our old PTO tool is called InTech Time, and it connects to our team through an MCP directly inside Claude Cowork. Someone asks for three days off the way they'd ask for anything else in there, in plain language, inside the same session where they're already doing their actual work. The system checks it against their accrual and the intent we wrote down for it, approves what's inside policy on its own, and routes the rest to a person. Nobody opens a fifth tab to do it. Nobody logs into a separate portal to approve one. It happens inside the same tool our team is already working in all day, which is the same thing I described in July: the tell that a system is real is that it disappears into ordinary work instead of asking to be noticed.

I wrote in May that AI-native and AI-enabled sound interchangeable and are not, that one is a label retrofitted onto old architecture and the other is a foundation. A PTO request that lives inside the tool you already have open, instead of a separate app half the team has forgotten the password to, is what that distinction looks like when it's this unglamorous.

Nobody writes a case study about requesting a Friday off. That's exactly why it's good evidence.

We weren't performing for an audience. We were fixing our own back office, and the fix looked like the thing I've spent the year telling you to build.

One module, not the pitch

InTech Time is one module. CRAFT OS is bigger than PTO, and I'm not unveiling the whole map today on purpose. This piece is a look through one window, not the blueprint. It already sits underneath how we track capacity across engagements and how delivery work connects to what we bill for, and more of it gets built every month.

I'm not going to pretend it's finished. It isn't. Some of it is going to work the way rung two of the maturity model I described in July is supposed to, a connected layer that makes existing pieces behave like one system. Some of it is going to bump into the same limits I admitted to three weeks ago, the fourth rung that's still mostly theory even for us. I'd rather show you both kinds honestly than only show you the parts that make a clean story. I'll be writing more about CRAFT OS as it grows, the architecture underneath it and what it actually costs to build a layer like this instead of renting one, so consider this the first look, not the last.

Land the plane

Three weeks ago I asked who owns the coordination layer a business runs on, because that's the question that actually decides the next three years, not whether you adopted AI. Everyone will have. We own ours. Not as a slogan on a slide. As a module our own team used this month to request time off, built in two days on a system that was already there to build on.

The real test of whether a firm believes its own AI-native pitch was never the deck they show you. It's whether their own business would survive being audited against it.

I ran the audit on us this time, and I'm going to keep doing it in public. Up next: the reusable architecture underneath CRAFT OS, what it actually costs to build a layer you own instead of renting one, and the parts of our own maturity model we're still figuring out as we go. Less thesis, more blueprint, the same way I said we would.