Your Business Has To Be Readable Before AI Matters

About thirty years ago, a regional ferry company operating between Majorca, Ibiza, and Menorca asked me to solve what sounded like a simple problem.

They moved trucks, cars, and passengers across the Balearic Islands on ships with fixed capacity. Every voyage had a ceiling, and nobody actually knew how close they were to it until the ship either sailed or someone made a round of phone calls.

Reservations lived in notebooks. Capacity decisions lived in people's heads. The person at the port knew their slice. The travel agent knew theirs. Nobody had the whole picture until it was too late to use it.

I built them a real-time booking system that connected travel agents, transport companies, and ports into a single readable view of every voyage, every ship, every available space. The capacity utilization went up. Not because they suddenly had more ships. Because the information existed. The business became legible to itself.

That system is still running today, now extended to the Canary Islands, the Gibraltar Strait, and routes into the US. The company didn't double. It grew 25x.

The sequence nobody talks about

Here's the thing nobody is telling you right now, as the AI sales cycle reaches full fever pitch: the sequence matters. Legibility first. Intelligence second. Not the other way around.

AI has nothing real to work with if your business can't see itself yet.

A machine can't read how your operation runs if the way it runs was never written down in a language any machine can understand. It was written in people. In the office manager who knows which suppliers to call. In the estimator who carries the pricing logic in his head. In you, the owner, who is the actual operating system of the business whether you wanted that job or not.

We didn't add AI to that ferry company in 1995. We made it readable first. The capacity gains were not an AI outcome — they were a legibility outcome. The intelligence was just arithmetic, once the information existed in one place.

The complexity wall

I've been noticing a pattern across nearly forty years of building and advising on software systems. Businesses hit a wall, and it almost always happens in the same window: somewhere between fifteen and fifty employees.

Externally, things look fine. The business is growing. Revenue is up. Customers are happy enough. But inside, the operation is held together on pins and needles. Little black boxes connected to each other with no roadmap. Processes that exist nowhere except in the memory of whoever is doing them this week.

Two things happen at this moment that I hear almost word for word from owners across industries.

The first: someone went on vacation, had a baby, got sick, and a critical part of the operation seized. Not failed dramatically. Seized. Quietly. Because the knowledge lived in one person and that person was unavailable.

The second is harder to talk about. The founder dreads going to work. Not because the business is failing, but because every single thing falls back on them. They built the business to have freedom, and somewhere along the way it became the cage.

How AI band-aids make it worse

You solve one isolated problem with an AI tool. It feels great. You save two hours a week on something annoying. So you solve another one. Then another.

Eighteen months later, you have twenty separate tools and none of them talk to each other. None of them share a common database structure. None of them understand your actual business rules. They each have their own logic, their own storage, their own sense of what a "customer" or a "job" or an "invoice" actually is.

And you are the connective tissue between all of them.

This is what I call application slop — disconnected, non-integrated, non-scalable point solutions that don't survive contact with a real business. The slop compounds. The operation becomes less legible than when you started.

The disease is illegibility. Application slop is the symptom.

Where the real leverage is

People almost always apply AI to the fuzzy periphery of the business: social content, blog posts, support ticket routing. That's not where the leverage is.

Businesses run by delivering value to customers. The core of that is the transactional workflow — not the marketing around it, not the content about it. The actual thing the business does.

When your proposal tool doesn't talk to your scheduling system, and your scheduling system doesn't talk to your billing, and your billing doesn't talk to your accounting, the cost isn't a software problem. It's a business problem. It shows up in cash flow, in customer experience, and in the hours your office manager spends being the human copy/paste machine in the middle.

The story that didn't work

I want to tell you about a project I'm still proud of technically, but that didn't end the way it should have. Because the failure tells you more than the success does.

A regional home builder. Beautiful second homes, well-off customers. The owner worked eighteen-hour days — the fireman, the glue, the muscle memory of the entire operation.

We built the system. When we presented the first working version to the broader team, something became clear immediately: the language we had built the system in was the language the owner had given us. His mental model. His vocabulary. And the team spoke a completely different language.

The business wasn't legible even to itself. The owner couldn't accurately represent his own organization — not because he was uninformed, but because the complexity had grown past any one person's ability to hold it whole.

My mistake, looking back, is one I now ask about before every single engagement: I let the founder speak for the whole organization. I didn't insist that the key stakeholders were in the room from day one.

You can build exactly what you were asked for, and still get it completely wrong.

What IBM taught me about asking the right question

I started at IBM Austin in 1988, on the AIX Unix operating system. Thousands of engineers working simultaneously on a codebase where one wrong change could break the entire build for everyone.

That demanded you ask one question before every change: does this break the build?

Nothing was built in isolation. You couldn't ship a component that had its own sense of what a user session was, or its own interpretation of what an authentication event meant. The system had a shared reality, and your contribution either fit into it or it didn't.

Modern AI-assisted builds have largely abandoned that question. Every tool gets built in isolation, with its own database, its own logic, its own sense of what the core entities of the business actually are.

The tools change. The failure mode doesn't.

What's actually possible now

It has genuinely never been easier or cheaper to build the connected, legible business. The equivalent of that ferry project today — architecting a system that connects the real workflows of a 30-person operation and puts real-time operational visibility in the owner's hands — costs a fraction of what it cost then. And it moves in weeks, not years.

But easier doesn't mean effortless. Understanding what the business actually does, which integrations create real leverage versus which ones just feel like progress — that's still irreducibly human work. No tool does it for you.

The best tool in the world, dropped into a business that doesn't understand its own operation, produces another black box to manage.

Find a partner willing to understand how your business actually runs — not just the version the founder describes, but the version the people doing the work live.