So you're saying we're not ready for AI?

Almost every business can get value out of AI immediately. The issue is that most are ready for a smaller piece of it than they were sold. What's often missing is connected, clean data for it to work from, and that's buildable.

We already have someone technical in-house. Can't they do the plumbing?

Sometimes, and if they can, you should use them. The part that trips people up isn't writing the code, it's knowing which systems hold what, in what shape, and what everyone in the building means by the words in them.

Ninety days feels long. Is there a faster version?

There's a narrower version, which isn't the same thing. We can scope to one function rather than one department and finish sooner. We can't scope out the part that makes it keep working.

What if we just want the audit and not the build?

That's a fair ask and a different conversation from a la carte on delivery. Knowing what's broken and in what order is useful on its own, and you can take that anywhere.

Why not run a pilot to prove the value before committing?

Because a pilot built on hand-fed data proves the model can write, which you already know. It tells you nothing about whether it will run in your business, and that's the only question the pilot was supposed to answer.

Why We Don't Sell AI Pilots | Janaitis Business Systems

The call usually opens one of two ways. Either “I know I need to get AI going, I don’t know where to start, and I need somebody to come build some skills for my team.” Or “we already bought the Claude Pro membership and we’re not getting anything out of it, so I need somebody to run a pilot.”

Both of those are reasonable things to want. Plenty of people will say yes to either one on the call and start the following week. Here’s why we take a slightly different approach.

We won’t build you an AI pilot so you can say you’ve run an AI pilot, and we don’t do a la carte. You can’t pick the skill out of the project and leave the plumbing, because a skill with nothing feeding it won’t produce reliable results, and a skill that isn’t shared and useful to the team is a demo, not a process.

First, the objection I get

Nobody asks me why I can’t build the connective tissue and run the pilot at the same time, and if they did, the answer is that we can. That’s exactly what we do. We take it on as one project, build the underlying connection first, and put the skill on top of it. It’s one engagement, not two.

The pushback is about money and about the calendar. It sounds like: you told me doing this right costs nine thousand dollars over ninety days, and I don’t have ninety days, or that’s more than I want to spend up front. Why can’t you just write us the Claude skill and skip the rest?

That’s the version worth answering honestly, because it isn’t a stupid question.

What you’d be buying instead

A very good demo.

We could stand up a pilot with a lot of manual work around it. You export the spreadsheets, pull the CSVs out of your systems, forward the emails, and hand all of that over. We point a skill at it. It produces a drafted email, or a finished report, or a sharp piece of analysis, and it’s impressive in the room. Lots of people will build you exactly that.

Then it has to run next week without me there, and here’s where it goes. Your team member has to gather up all that material again before they can start. Nobody told them that part is their job now. It takes twenty minutes, they’re busy, and they do it twice and stop. The skill still works perfectly. It just never gets run.

That’s not a training problem you can fix afterward with a better handover. The question is whether somebody on your team can kick this off with a sentence, or whether they have to go assemble the inputs first. If it’s the second one, the tool has a shelf life measured in weeks and it isn’t dependent on how good the tool is.

Anybody can prompt Claude into writing a skill that solves a particular problem well. That part is close to free now. Whether it’s connected to the right systems, and whether those systems are clean and talking to each other, is what decides whether it’s still running in six months. The context is the most important piece.

The version of this that costs me the most

I’ll give you the strongest evidence I have for this problem: it’s why we refuse to sell our own Claude Code-driven operating system.

We’ve built an internal operating system that runs most of our business, over the better part of a year. It works extremely well for us. When we’ve shared it with people, the question I get back is why I’m not selling it as a product.

I’m not, because I don’t think it’s a production-level tool in anyone else’s hands. Things break. You have to check the output and think critically about it. It’s connected through Google Drive, and sometimes that connection drops. If you’re not watching for that and you don’t catch it, you can run for days on outputs built from a stale version or missing the current client context, and everything will look fine. Catching that takes a technical bent and real time on the tool.

So it’s a system that fits three experienced people who built it. Handed to a larger team, or a less technical one, it would degrade, and the degrading would be hard to spot. Selling it would be selling something that works for my team and calling it something that works for yours.

That’s the same refusal, aimed at myself. Building something that works for one team is not the same as building something that works for another, and if you skip understanding the second team, you’ve built the wrong thing well.

What we’d build instead

Something much smaller than you asked for, that runs.

Say the target is your inbox. We’d start with triage and nothing else. We write a skill that gets loaded directly into Claude, so it isn’t a local file living on somebody’s machine and it isn’t something the user is expected to edit. We own the editing, the error checking and the troubleshooting, which takes all of that off your person’s plate. It connects to the email system and only the email system, and it helps triage the inbox and nothing else.

Then they use it for a while and get comfortable. When they’re ready, we show them what the underlying skill looks like and how to ask Claude to change it if they want it tweaked. That’s when it starts to belong to them.

Starting narrow and widening is slower on paper and it’s the version that’s still in use next year. It’s also safer, because a smaller surface has fewer places to be wrong without anyone noticing.

What the first stretch gets you

From the outside this reads as a delay, and I want to be straight about that: it is one. It takes longer and it costs more to do this part.

What happens in it is that we interview your people and find out how the work runs, not how the org chart says it runs. We find out which systems the data lives in and what state it’s in. We figure out where the connective tissue has to go and build it. Then we make a call about where the tool should live given who’s going to use it, whether that’s Claude Code, shared skills inside your Claude instance, local files or a repo, and that’s a decision about your team’s technical range rather than a preference of mine.

What you get at the end is one function that works, unattended, and takes something off somebody’s plate permanently. What you’d get from the other path is either a broad tool that doesn’t do anything well, or a single sharp demo that’s fun to watch and requires too many manual steps for anyone to keep running it.

We won't put AI on a business that can't feed it