Building our own systems

Two weeks ago I wrote to you about Bolt Farm Treehouse and what Seth and Tori have taught me. On our call last week they showed us something new: an operating system they built themselves. Not a stack of software they rent. One thing, built for their business, doing the work that fifteen other tools used to do. Their software spend dropped to almost nothing, and every piece of information about every guest who's ever stayed with them now lives in their house instead of somebody else's.

I've been thinking about it ever since.

We haven't broken ground. I'm working on operations software for a resort that doesn't exist yet, which sounds like the least urgent thing I could possibly be doing. I don't think it is. This is a big build and I'd rather spend the pre-construction runway on it than try to figure it out while guests are actually arriving. By the time someone checks into the first unit, I want the system underneath them to be boring. Solved. Invisible.

What I'm after is an AI-first operating system where the pieces talk to each other and handle the routine work on their own. Not because I want fewer people. Because I want the people we hire doing the thing they're actually there for, which is caring for other human beings. Being fully present with a guest. Not heads-down troubleshooting some technical issue while that same guest is trying to reach us about a problem in their unit.

Here's the reality of running short-term rentals right now. Property management in one place. Pricing in another. Guest messaging somewhere else. WiFi capture in a fourth. Accounting fifth. CRM sixth. Every one is a login, a monthly bill, and a place where what you know about a guest sits stranded from everything else you know about them. Nobody sat down and designed that. It just accumulated.

And there's no single screen that pulls it back together. You can see six versions of a problem without ever seeing the problem. Finding out what's actually going on means opening six tabs and doing the assembly yourself, every time.

The cost isn't really the money. It's what those seams do to the guest.

When your systems don't talk to each other, the property doesn't remember someone stayed last spring. Nobody knows it's their anniversary again. The person answering a message at 9pm doesn't have the context that would let them answer it well. Personal attention leaks out at every seam. Cavara is supposed to be the opposite of that. A stay for someone who wants to feel like a person, not a reservation number. You can't deliver that on infrastructure that treats them like a row in six different databases.

Same argument I made in the first email I ever sent you. I left stick-frame cabins because anything you can buy from a catalog, anyone can copy. Cabins from a Wayfair cart, software from a subscription page. Same ceiling.

So I started building.

I want to be honest about what that is. It's live, it's password-protected, and it's mostly a shell. One working module. The rest are placeholders with names on them. A year ago I couldn't have told you what a database was, so I'm not going to pretend I've built an operations platform in a weekend.

The module that works is website health. It scans the site for broken links, forms that stopped submitting, pages loading slower than they should. When it finds something, it tells me what's wrong, and a few clicks later it's diagnosed, fixed, and pushed live. Small thing. But it's the difference between finding out a form is broken because the system told me and finding out because a subscriber emailed asking why nothing happened when they hit submit.

Analytics is next, and the questions I want it answering are newer than the usual traffic-source stuff.

When someone searches for unique places to stay in the Gorge, where do we land? First page, or page four?

And the one nobody was asking two years ago: when a guest asks Claude or ChatGPT to help plan a Red River Gorge trip, does Cavara come up? A real share of trip planning has moved into those conversations. Being invisible there is a different problem than being invisible on Google, and it has to be measured differently. That's the kind of thing I'd rather watch inside something I built than wait for a dashboard someone else decides to show me.

The plan from here is patient. I'm not replacing everything at once. Start on proven third-party tools, use them long enough to learn where they actually fall short, then replace them one at a time when there's a real reason. Build the thing you understand, not the thing you imagine.

Same discipline as cutting phase one down. Restraint is cheaper than rework.

Worth mentioning: staycavara.com was built the same way. An afternoon with Claude Code, no technical background. If you're a small operator reading this and assuming you need a dev team to own your own tools, that assumption is more out of date than you think. There's a longer email in that one, and it's coming.

More soon,

Jeremy