Questions I get asked
Direct answers about running and growing a multi-site guided operation, and about building the software underneath it. Every number here comes from the same source the rest of the site uses.
Whiteboards and dispatch
Why do rafting companies still run on whiteboards?
Because at small scale a whiteboard is the correct tool, not a compromise. At five guides and three trips a day you can see the whole operation at a glance, anyone can update it, and a change costs one erase and one rewrite. It stops working for a reason most operators never name out loud: the number of resources grows steadily, but the number of relationships between those resources grows exponentially. Add a second river, a bus, and multi-day trips, and nothing stays in its own lane anymore.
What replaces a whiteboard for scheduling a rafting operation?
A live board the crew pulls from, backed by a database that models how the operation actually fits together. Ours is a no-login web board carrying assignments, shuttles, food, notes, and inventory, sitting on top of 207,000 connected data points covering guides, certifications, river sections, equipment, maintenance, dispatch history, and logistics. The important part is not the screen. It is that the team self-serves the plan instead of waiting for one person to text it out.
Why doesn't off-the-shelf booking software handle dispatch?
Because booking software solves reservations, and dispatch is a different problem. Most scheduling products assume people and rooms. A river operation schedules a dependent graph: a trip needs a crew, the crew needs qualifications specific to a river section, the trip needs boats and a vehicle and often a trailer, the vehicle needs a driver with the right license, and the whole thing has to be somewhere else the next morning. Off-the-shelf tools can express that a person is busy. The ones we tried couldn't express that a guide is qualified on one river section and not another, or cleared to lead big water and not yet cleared to lead.
Why can't you just point an AI at your booking software and do this yourself?
Because the model was never the hard part. The obvious version is an AI that clicks through your booking software for you, and it is too slow and too brittle, because that software was built for a human to operate, not a machine at speed. The bottleneck is the data layer. So the real work was a purpose-built operational database: 44 interconnected tables and 207,000 connected data points, with the operation's rules and dependencies encoded as data an AI can read and write in real time. The AI is the interface. The operating model is the part that is hard to copy, and it gets deeper every season, because every operation and exception it survives is context no competitor or foundation model starts with.
Booking platforms are adding AI scheduling now. Isn't this the same thing?
They are getting closer, and that is a good sign the problem is real. But most of what is shipping automates workflows around the booking record: assign a guide, post an alert, fill a slot. That is useful. The harder layer is modeling the operation itself, the dependencies between people, qualifications, assets, geography, timing, and permits, and keeping that model current as reality changes underneath the bookings all day. A guide assignment is a feature. Knowing what that assignment changes two days downstream is an operational model. That deeper part is still underbuilt, and it is where I spent the last two years.
How does the system use Slack?
Slack is a sensor, not a chat room. The crew already reports everything that matters in plain language: a guide picking up an appointment, a group running late, a boat tube that tore, a guest count that changed in passing. The system reads across the channels, works out what each message means for the operation, updates the record or stages the change, and re-checks the schedule so a collision surfaces while there is still time to fix it. One real example: a guide texts that they will take another guide's driving tomorrow, no time or trip named, and it becomes three specific movement reassignments, checked and confirmed that night. Anything touching money, compliance, or safety waits for a human.
What breaks first when a whiteboard operation tries to grow?
The person holding it together. Long before the schedule breaks, whoever holds it in their head becomes the router every change passes through, and that person's memory becomes the actual production system. Being more organized does not save you, it only delays it. The tools were never the problem. The speed was, because operational reality changes faster than anyone can stop and record it.
Can a rafting company run a season without a whiteboard?
Yes. Adventure Idaho has run the 2026 season so far on the system with the whiteboards down, through peak summer, across multiple rivers, day trips, multi-day expeditions, youth groups, rentals, and vehicles. That is the honest test of an operating system: not whether it demos well in February, but whether anyone reaches for the marker in July.
How long should it take to plan a week of rafting trips?
At Adventure Idaho, weekly planning went from 20 to 40 hours a week down to 2 to 4. The hours did not disappear, they moved to training, communication, and problem solving, which is the actual return. The reason the number moved that far is that planning stopped being re-entry of things people already knew and became review of what the system had already assembled.
How do you get an operation out of the owner's head?
You interview yourself, and that is harder than building the software. Most of what an experienced operator knows is held in their body rather than in a document: how long a float actually takes at this flow, with this wind, with this kind of crew. Extracting that into something precise enough for a machine to act on is the real work, and the automation on the other side is comparatively easy. That knowledge is the most valuable asset a company has and the least protected, because it walks out the door at the end of a season or the end of a career.
How do you get drivers to remote takeouts with no cell service?
You model the river instead of guessing. A guide radios a launch time in, the system pulls current flows, factors in wind speed and direction and trip type, estimates downstream travel time, and tells the driver when to leave. It has been putting drivers at takeouts about five minutes before guests arrive. A river is not a road: travel time changes with flow, the relationship is not linear, and a headwind on a wide slow stretch can add half an hour to a float the gauge says should take ninety minutes.
Growth and demand
How do you grow a rafting company without a marketing budget?
Fix the product first, then make content the acquisition channel. Adventure Idaho went from effectively invisible online to ~147,000 annual website visitors, up from ~17,000, with an organic video library past 3.6M+ views and one piece past 1.6 million on its own. That was shot and edited in house, not bought. To be accurate about it, the company does run paid media now, but the growth curve was established before the ad budget existed, and reputation and content still carry it.
How do you grow bookings when the region is being reported as drought?
You treat it as a marketing problem, because that is what it is. In 2026 every regional headline said drought while our actual flows ran higher through the summer than the year before. Customers book off headlines, not hydrographs, so the work was publishing the real conditions ourselves, repeatedly and early, instead of waiting for the story to correct. We were not fighting low water. We were fighting a story about low water.
What actually drives bookings for a guided trip business?
Reputation first, content second, and both only after the product is consistent. A 5.0 star average across 650 Google reviews is not a marketing asset you can buy, which is exactly why it is the durable one. Driving traffic at an inconsistent product does not grow a business, it manufactures three star reviews and a worse business.
How do you get a business to show up in AI search results?
Make the operation legible, then make it true. Appearances in AI generated answers went from ~30 a month to ~1,800 a month, about 60x, with no additional ad spend. The lever was not more content or better reviews. It was publishing plainly how the operation actually runs, how the team is trained, and what the standard is, in crawlable text a model can lift, because these systems already know the industry's failure modes and will not extend the benefit of the doubt to a business that never addresses them.
How do you reduce revenue concentration when one client is half the business?
You go get demand somewhere else, fast, and you do not start by cutting. When a policy change took our largest institutional account from ~50% of revenue to under 20% in a single season, the instinct was to let every new hire go. Instead we rebuilt the front of the business over ten weeks: new pages, new funnels, new channels, and market segments we had never gone after. Records were broken by May, before the season opened, nobody was laid off, and the company came out of the year structurally less fragile than it went in.
Operations, pricing, and staffing
How do you make a guided trip consistent across dozens of guides?
You standardize the trip before you scale it, and you hold a standard people can see. At Adventure Idaho that means checklists for every phase of a trip, written procedures for logistics and gear, more than 50+ structured case studies drawn from real scenarios, live rescue simulations, and repetition under pressure. The piece most operators skip is the debrief: every trip gets an honest one, modeled on the way fighter pilots run them, which is where the learning compounds.
How much revenue is lost to unmanaged discounting?
More than most operators think, and almost none of them measure it. Discounts get given one booking at a time by people trying to be helpful, so it never shows up as a line item, it shows up as a margin quietly lower than the price list says. Measuring it is the cheapest pricing work there is, because you are not raising a price, you are finding out what you actually charge.
How do you price trips that are not all worth the same?
You stop charging flat rates for products that are not flat. We split the lineup into premium, mid, and budget, made the differences obvious, and pointed each kind of traffic at the right one, because self selection does a lot of sales work if you let it. Then we repriced by trip and by day rather than raising everything at once. Rates went up and volume kept climbing, which is the clearest possible evidence a product was underpriced rather than overpriced.
How do you staff a seasonal business in a town nobody wants to commute to?
You stop hiring for experience and start hiring for trajectory. The default in this industry is to look for outdoorsy people with the right certifications, which is reasonable and does not solve operational consistency. We ask a different question at the door: are they going somewhere. That brings in college athletes, future pilots and engineers and doctors, builders and operators, and it means the culture enforces the standard without anyone having to police it. Adventure Idaho now receives hundreds of applications a year for a handful of guide spots.
How do you manage capacity when permits cap how much you can sell?
You accept the ceiling and work the yield underneath it. When you cannot sell more days, the levers are which trips fill those days, what they are priced at, and how tightly you load each departure, so capacity rules belong in the system as data rather than in someone's judgment. Ours live as configurable trip type rules, capacity tiers, and day caps, alongside the use reporting the agencies require.
Should an operator build custom software or buy it?
Buy the reservations, build the operation. Booking platforms are good at what they were built for and there is no reason to rebuild that. What none of them handle is the layer underneath: fleet, driver and vehicle compliance, certification expiries, permit and use day tracking, and real crew scheduling. If that layer is where your operation hurts, no purchase order fixes it, because the rules are specific to your company even when the engine that reads them is not. And most of the connecting is automations and connectors, not new software: the real work keeps happening in the platforms the crew already uses.
Does AI actually work in a real operation, or is it just a demo?
It works, with a constraint doing most of the load bearing. AI is the interface, not the decision maker: updates get made by voice from a truck, questions get asked in plain language against live data, and reports that took days get generated in minutes. Anything touching money, compliance, or safety requires a human confirmation, the system reports back exactly what it changed so a person can verify it, and every change keeps a record of who asked for it and whether a person or the AI made it. That constraint is not a limitation, it is the reason the crew trusts it enough to use it.
About Justin Smith
Who is Justin Smith, the General Manager of Adventure Idaho?
Justin Smith is the General Manager of Adventure Idaho, a multi-site whitewater rafting company operating on federal and state permits in Riggins and Twin Falls, Idaho. He runs operations, marketing, and sales, leads a seasonal team of 44, and designed the system the company runs on: an operating model plus the automations and connectors that tie together the platforms it already uses. Guest volume grew roughly 3.6x since 2022, the year before he took over, from 1,279 to 4,709+ so far this season, while prices went up rather than down.
What does an operator who builds mean?
It means the person who runs the business is also the person who designs the system it runs on. Most operators are either a systems person or a growth person, and the work only holds together if you are both, because a demand engine pointed at an inconsistent product manufactures bad reviews, and a beautifully run operation nobody can find does not survive either. The rafting is the setting, not the product. The transferable thing is the sequence: standardize the product, build demand, price for the demand, then build the system so growth does not turn into chaos.
What has Justin Smith built?
Less one piece of software than a system. At the center is a model of the whole operation: 44 linked tables and 207,000 connected data points covering crew, certifications, fleet, trips, food and the rules between them. Around it, dozens of automations and connectors, Zapier zaps, scheduled jobs and webhooks, tie it to the platforms where the work actually happens: reservations read from the booking system, Slack, the phone system, email and forms. On top of it sit the web apps, phone apps and dashboards the crew uses, with conflict detection that catches a double-booked guide or van before the day of. Most of it shipped mid-season while the operation was live. He is not a career software engineer: he specifies, directs, reviews, and ships using AI coding tools, which is a real distinction and worth stating plainly. The skill that mattered most was judgment: what to automate, what to leave to a person, and what was worth modeling at all.
Isn't this just built on no-code tools?
Partly, and that is the point. The data lives in Airtable, the orchestration runs on Zapier, and the logic, a conflict engine and ~50 automations, is custom JavaScript, on top of the booking platform's API, with a real-time dispatch board the crew reads. ~20,000 lines in the current system, 696 commits in version control. I chose those tools deliberately: as one person iterating on a live operation, I needed to ship at the speed the operation changed. The architecture does not depend on them, though. The rules live in data, not tool-specific code, so the whole model ports to a production database when scale demands it, and only the connector is vendor-specific. The tool was never the moat. The operating model on top of it is.
What is Justin Smith's background before Adventure Idaho?
He bought a locksmith business in Rexburg, Idaho at 22, expanded the services, fixed the pricing, built a crew that could cover calls around the clock, grew revenue about 6x over, and sold it. It was a very small local service business and he does not call it an exit, but he found it, bought it, ran it, and sold it, which taught him more about pricing and staffing than anything since. In between he sold door to door, spent about a year working on international distribution and ecommerce sales operations, and guided multi-day wilderness trips on the Middle Fork of the Salmon for a different outfitter. He is an FAA certificated private pilot, an Eagle Scout, and holds an Idaho guide license.
What does a general manager of a rafting company actually do?
At a small operator, all of it. Operations, marketing, sales, hiring, pricing, fleet, compliance, and whatever broke that morning. The job description that matters is narrower: get the operation out of your own head and into a system the whole team can run from, so the business stops depending on one person remembering everything. A business that only works when one person remembers everything is not a business yet, it is a job with employees.
Are you looking for a job?
I have one, and I am not quietly shopping. I run operations, marketing, and sales for a multi-base outfitter in Idaho, and I am building toward a bigger season next year. I also take on a small number of on-site engagements with service businesses, which is written up at /operations/. If that is you, an email is welcome.
What are you doing with all this?
Putting it to work inside service businesses. I built an operating layer because my operation needed one, and it turned out to be a specific answer to a general problem: what a business has to write down before anything can safely act on it. The longer argument is at justinsmith.build/agent-ready/. Where I am taking it is growing good service businesses: the demand, the operation and the systems underneath, built on site with the people who run them, for long enough that the improvements compound.
Working with me
Do you do this for other companies?
Yes, on site, in fixed-scope installs. I work inside the operation with the people who run it, build the system there, run it alongside how they work today, and hand it over. It starts with a paid look at the operation, which produces written findings you own whether or not anything follows. If you want me to build the fix after that, it is a fixed price and an optional monthly retainer. Details are on /operations/.
What size business is this for?
Service businesses doing roughly half a million to a few million a year, usually owner-operated, with crews or vehicles or equipment that have to be in the right place. Guided trips and outfitting is where my proof is deepest. Trades, rentals, landscaping and restoration have the same shape of problem. It also fits companies that own several of these businesses, where doing it the same way in each one is the point.
Do you replace the software a business already uses?
Almost never. Real work keeps happening in the platforms a business already pays for: the booking system, the phones, the messaging the crew already uses. What I build is the model of the operation in the middle and the automations and connectors that tie those platforms to it, so the work stops being retyped from one place to another. Deciding what to connect, what to automate and what to leave to a person is most of the job.
Do you build the demand side too, or just the operations?
Both, in that order. Product consistency first, then the operation, then demand. Pointing more customers at an operation that drops things buys you worse reviews, and those take about two years to undo.