PTO Was the Easy One to Explain

CRAFT OS started with the money and the pipeline. This is the rest of the map, and where it's headed next.

The order I got wrong

Last week I told you about InTech Time, the module we built to replace our old PTO tool, and how it lets our team request time off from inside the same Claude Cowork session where they're already working. Some of you read that and drew a reasonable conclusion. That this was the beginning. The founder finally turning the CRAFT OS lens on his own business, one module in, more to come.

That's not quite right, and I'd rather fix it now than let it become the story people tell about us.

InTech Time wasn't the beginning. It was the newest thing we'd built, not the first.

It was also the easiest one to explain to someone outside the business. Nobody needs a walkthrough to understand what a time off request is. Most of what came before it is harder to make sound interesting, even though it mattered more.

What actually came first

Before we ever touched PTO, CRAFT OS was already running the two things that matter more to a business than anyone's vacation balance: the money, and the pipeline.

Early on, we tied our financial systems together. Bookkeeping, payroll, invoicing, the stuff that used to mean three or four separate logins and a mental map of which number you actually trusted. Around the same time, we replaced our CRM. Not upgraded it. Replaced it, the same way we'd later replace the PTO tool: decided the rented version was never going to hold the context we needed it to hold, and built something on CRAFT OS that would instead.

I'm not naming what we replaced, on either front. Not because it's a secret. Because the vendor was never the point, and saying so out loud is easy to agree with and hard to actually act on when a rep is on the phone offering you a discount to stay. The point is what those two categories represent. Financial systems tell you what's actually happening to the money: what's owed, what's coming in, what a project is really costing against what it's billing for. A CRM, or whatever you want to call the thing that tracks a pipeline, tells you what's actively being worked on and for whom. Together they answer the only question that matters most mornings: where does this business actually stand right now, not where did it stand two weeks ago when someone last updated a spreadsheet.

The CRM mattered for a reason that goes beyond just knowing who to call. It was the only place that could eventually answer whether a prospect turning into a client meant we actually had the capacity to serve them well, or whether we were about to commit a team that was already stretched. A rented tool that doesn't talk to the system tracking delivery work can only tell you a deal closed. Whether closing it was a good idea is a different question, and before these systems were tied together, that question got answered from memory instead of from data.

I argued back in June that CRAFT runs a business, not just software delivery. That wasn't a thesis waiting on proof. It was already true when I wrote it, I just hadn't shown you what it looked like yet. This is what it looked like, before any of it was a module you request time off through: two unglamorous systems, tied together early, because a business that doesn't know its own numbers in real time is guessing at everything downstream of them, including whether it can afford to hire, or needs to.

Before any of this was tied together, answering a simple question, are we in good shape right now, meant pulling from three or four places and hoping they agreed with each other. They didn't always. That's not a dramatic story. It's just what happens when the systems that are supposed to know don't talk to each other, and it's the same failure mode I've described for clients a dozen times, just with our own name on it this time.

We didn't lead with this publicly because it doesn't read as a story. Nobody wants to hear about someone else's aging report. But it's the part that was actually hard, and the part that had to be right before anything else got to be interesting.

Connect versus isolate

Here's the distinction I got sloppy about last week. I framed the PTO piece as build versus rent, and that's true as far as it goes. But build versus rent was never really the question underneath it.

The real question is connect versus isolate.

InTech Time we built from scratch, the same way we rebuilt our CRM. Our financial systems, we didn't rebuild those. The specialist tool in that category was already good at the one thing it does, and reinventing double-entry bookkeeping from zero would have been the same mistake pointed the other direction: burning weeks solving a problem that was never really about the software. The problem was never which tool did the work. It was that each of these lived on its own island. Its own login, its own export somebody had to remember to go pull, its own version of the truth that quietly drifted from everyone else's.

So the real test, every time, was the same one. Does this report into the layer the team already works inside, or does someone have to go get it. It doesn't matter whether the answer came from something we wrote ourselves or the best specialist tool available to rent. What matters is whether it joined the layer or stayed an island charging a monthly fee for the privilege.

Think about how you actually run into this yourself. A tab open for the accounting tool. A different tab for the CRM. A phone open to whatever's tracking social. None of them wrong to use on their own, all of them fine software, and none of them able to answer a question that spans more than one of them without a person doing the spanning by hand. That person was usually me, which is its own kind of tell.

The parts that face outward

The same test applies to the parts of the business that face outward instead of running the inside. Social and website performance are the clearest examples, because they're the ones most businesses check least. Someone glances at a dashboard on a Friday, or more honestly, opens it for the first time in weeks right before a client asks why a post underperformed, and otherwise it sits there collecting numbers nobody acts on.

We run our own local search and content work on a schedule, against specific milestones, measured against what's actually moving instead of how it feels. That means actual milestones, not just intentions. Getting the basics right first, because nothing else matters if those are wrong. Then the content and technical work that actually moves a ranking. Then measuring whether any of it produced a call, a direction request, a form fill, the things that actually matter instead of the vanity numbers most dashboards lead with. We did it to ourselves before we'd ever pitch it to a client, the same audit-your-own-business instinct that caught the PTO problem and the CRM problem before it. I'm not going to walk through the whole playbook here. Some of what we've learned running it on our own business is turning into something we'll eventually offer clients directly, and I'd rather show you results once they're real than describe a plan while it still is one.

What matters for this piece is the pattern repeating a third and fourth time. Performance data that used to live in a tool nobody opened now reports into the same place as everything else. Not because checking it more often is some breakthrough on its own.

A number nobody sees might as well not exist, and a business that can't see its own website the way a stranger does is negotiating blind.

The one we already proved

Which brings me back to InTech Time, and why I think it's actually the most useful thing to point at even though it wasn't first.

Every category I've walked through so far reports into CRAFT OS. You can see the money. You can see the pipeline. You can see what a post or a page is actually doing. But seeing isn't the same as acting on it, and PTO is the one place where we skipped past seeing and went straight to acting. Nobody checks a PTO dashboard and then goes somewhere else to file a request. They ask, in plain language, inside the same Cowork session they're already working in, and the system checks it against policy and either handles it or routes it to a person. No second tab. No separate login half the team forgot the password to months ago.

Compare that to how the other categories work today, even connected. Somebody can see that an invoice is thirty days overdue. Seeing it doesn't send the reminder. Somebody can see a lead has gone quiet. Seeing it doesn't follow up. The system knows. A person still has to leave the flow of their actual work, go open the other tool, and do the thing by hand.

That's the gap between a connected layer and a platform, and it's a bigger gap than it sounds like from the outside.

That's the gap I actually want to close for the rest of these categories, and it's what we're building next. Financial systems, the pipeline, social, website performance: right now they mostly report in. You can look at all of it from one place, which is already further than most businesses get. What's next is the same pattern that already runs InTech Time, an MCP service extended outward, so those categories stop being things you go check and start being things the team can act on without leaving the room they're already standing in. Approve an invoice the way you'd approve a PTO request. Ask what a lead's status is the way you'd ask anything else, in the same session, and get an answer instead of a login screen.

I don't have a finished version of this to hand you yet, and I'd rather say that plainly than round up. What I have is proof it works, because we already built it once, for the category everyone finds easiest to relate to. The harder categories are next.

Land the plane

A couple of weeks back, I asked who owns the coordination layer a business runs on, and said that question decides the next few years more than whether you adopted AI. I keep coming back to it because it keeps being the right question. This piece is closer to a real answer than the last one was. I've written before about the stages a business moves through here: scattered tools, a connected layer, governed autonomy, and eventually a system that spans the whole business. Most of what I've shown you today is the second stage, with pieces of the third starting to show up. I'm not going to pretend it's further along than that.

A platform isn't a slide or a roadmap, and it isn't even really a list of what's connected. It's whether the people doing the work can act on what the system knows without leaving the room they're already standing in.

We're not there for all of it yet. We're there for one category, and building toward the rest, in the open, including the parts that aren't done. Next up, the piece I've been promising for a few weeks now: the actual architecture underneath all of this, and what it costs to build a layer you own instead of renting one. Less thesis, more blueprint, the way I said I would.