Justin Smith

Build it centralized. Run it distributed.

Before the system, planning a week at Adventure Idaho meant a whiteboard, a stack of spreadsheets, and too many other places.

What the whiteboard had to hold:

The connections between all of it lived in my head. Move one guide and you check their qualifications, their other trips and who could cover. Change one guest count and the whole week shifts. Every night meant reworking the board, retyping a long dispatch message, and fixing whatever the replies turned up. Planning took 20 to 40 hours a week. (The full whiteboard story is here.)

Then, before this season even started, bookings hit a record. Customers had more than tripled and website traffic was up nearly twentyfold. The season before, I’d already hit the limit of what one person could hold on a whiteboard. We’d tried different software, but none of the tools we tried could capture the complexity of the operating rules behind our scheduling.

What replaced it wasn’t a better whiteboard. It was an operating database for the whole company: every trip, guide, qualification, boat, van and rule in one structured model. The crew’s apps, the automations and the AI all read from it and write to it. The board is just one window into it.

It was built in weeks, on top of a couple of seasons learning the operation, then corrected all season until it was right. Planning dropped to about 2 to 4 hours a week, by my estimate.

Before

Our whiteboard during the season: a week of trips across the top, guide names written and rewritten under each day, multi-day trips drawn as lines across several days, vans and shuttles squeezed into the gaps, arrows and question marks where something still didn't fit.

The plan, in marker and memory.

After

The crew board: each guide's row across two weeks, showing which trip they lead or guide each day, their driving shifts with the van and pickup point, days off, a conflict flagged in red, and an open panel to reassign a guide to another trip. Names redacted.

One window into the operating database.

What it runs now

The board is the part people can see. Here’s some of what runs underneath it:

That’s the short list, and there’s a lot more running behind it. None of it is one app. It’s one structured model of the business that the AI can read and write to, within limits, connected to the tools we already pay for, with an interface the crew actually opens. (The architecture is here.)

When people hear “built in weeks,” they assume AI did it, or it wasn’t that hard. Neither is true.

The hard part was never the code

The expensive part of a system like this was never the code. It’s writing the business down, and that takes judgment, most of it not technical: what the system should decide, what it should only flag, and what it should leave to a good person. Get those wrong and you build something nobody uses.

Five jobs, no handoffs

In most companies, that work passes through five people: the one who knows the work, the one who decides, the one who builds, the one who uses it, and the one who signs off. Every handoff costs days: a meeting, a spec, a misunderstanding, a sign-off, a security review. It’s why so many companies bought AI and never connected it to the business. The tools work. The project dies in the gaps between the people.

As GM I was all five. A question asked at breakfast was a change in the system by lunch, tested on the afternoon trips. Zero distance between knowing, deciding and building.

It wasn’t because I knew every rule

Nobody who runs an operation knows every rule, me included.

When I went looking for the rules nobody had written down, most of them came from one place: the override log. Every time someone overruled the system, it left a record. 14 of the 18 unwritten rules I found came from there.

So the speed came from building early, expecting mistakes, and making it easy for the people doing the work to catch them. That gives you three phases.

1. Build it centralized

One builder. One person who decides what’s true. Move fast.

Build with confidence, knowing parts of it will be wrong: a data model that doesn’t fit, a rule nobody has written down yet. The first version doesn’t need to be perfect. It needs to be good enough to use and specific enough to argue with. A rule that’s wrong in plain sight gets fixed. A rule nobody wrote down stays invisible until a trip goes sideways.

You can’t skip this step. An override log only exists once there’s something to override. A whiteboard never records anyone disagreeing with it.

2. Let the crew correct it

Then put it in front of everyone who does the work, and make correcting it easier than ignoring it.

Make it easier than the whiteboard. Put it on their phone, one tap away, and in the team chat they already use. If checking the system takes longer than glancing at a whiteboard, they’ll keep the whiteboard and you’ll never hear what’s wrong.

Let them change it, and make the system push back. Drag a guide onto a trip or type a name, and the system flags any conflict. A hard conflict only goes through with a deliberate override, and it stays on the trip, crossed out, so everyone can see what was decided.

Read the overrides. Each one is a missing rule, a rule that needs clarifying, or a bad day. Fix the first two. Keep a person in the loop for the third.

Each round is less wrong, and the overrides that remain are the rare, expensive rules worth knowing. It helped that debriefs were already how this crew worked, from the training program. Correcting the system became part of the same habit. By midseason, the crew checked the board on their phones before asking anyone, and the day-to-day questions to management mostly stopped.

3. Then hand it over

Centralizing is how you build it. It’s a terrible way to run it. A business that routes everything through one person is fragile, however good the person is.

So name an owner inside the company, write the rules down where the next person can find them, and run the new system alongside the old way before you retire it. The test is simple: does it keep running the week the builder is gone?

Who should hold the keys

Centralize the building, not the ownership. Knowing what I know now, this is what I’d set up from day one:

None of that slows the build down. It’s what makes a fast build safe to keep.

What happens next

AI is already good enough. I’ve watched it read a crew’s messages, draft a week of assignments, catch a conflict before it reached the boat ramp, and turn a few sentences spoken at a gas station into a working fix.

The models aren’t what’s holding most businesses back. The organization is.

My prediction:

They’ll run far leaner than anyone thought a business their size could. Not by working people harder, but by deleting the work between people: the retyping, the chasing, the status meetings. Our office went from two people to three while the business more than tripled, and as the season got busier, those three spent more of their day driving shuttles than doing admin.

This is the work I’m taking into other companies: come in as the builder, connect what’s already there, let the crew correct it, and hand it over. For a company that owns several businesses, reuse the pattern and keep every company’s data and accounts separate.

If that’s the project stuck at your company, tell me what’s falling through the cracks. Or see how I work with companies and how I got here.

← All writing