I stopped building onboarding and built AI instead.

I watched screen recordings of my users being confused. So I stopped building onboarding and built AI instead.

Opencals is a booking platform for service businesses. Multi-staff, multi-location, orders, payments, customer management, service rules, capacity limits. It's a genuinely complex system because the problem it solves is genuinely complex.

But complexity has a cost.

At some point I realized the app had grown into something that looked and felt like a small Shopify. You've got customer management, order and payment management, locations, staff members, services, service-specific rules, availability configurations, and all the combinations between them. A new merchant signing up for the first time is staring at a lot of knobs.

I knew this was a problem. I just didn't understand how bad it was until I watched screen recordings.

The onboarding problem

I had onboarding. Several versions of it, actually. Tooltips, guided tours, video walkthroughs, help articles. I kept tweaking it. None of it moved the needle in any meaningful way.

The recordings were humbling. Merchants would land in the dashboard, click around for a few minutes, get stuck, and leave. Not because the features weren't there. Because they didn't have the mental map yet to know what to do first.

Here's the thing I eventually accepted: nobody actually reads documentation. Nobody watches tutorial videos when they're just trying a new app. They want to click three things, see something that looks right, and only then decide if this is worth their time. And that's completely reasonable - they're trying the app, not signing up for a course.

I'm building this alone. I can't hire a support team to manually onboard every merchant. And even if I could, that doesn't scale. I needed something else.

The obvious next step turned out to be the right one

Everyone is using AI now. That sounds obvious but it took me a while to actually act on it. When I added a chat interface powered by AI, I expected some merchants to use it. What I didn't expect was that nearly 100% of merchants use it, often before they touch any other part of the onboarding flow.

The moment you put a chat input in the UI with an AI behind it, people know what it is. They know they can ask questions. They know it will understand them. And unlike documentation, it responds to exactly what they're confused about, not what I guessed they'd be confused about.

But I didn't want to build a chatbot bolted onto the side of the app. I wanted to build something that's actually part of the infrastructure.

AI as an interface, not a feature

The AI in Opencals runs on the same API that the actual UI uses. The same API I've exposed publicly. When a merchant asks the AI to create a service, add a staff member, or block off a date range - it's making the same API calls that clicking the buttons would make. There's no separate logic for "AI mode." It's just another client.

This means merchants can do basically everything through the chat interface. They can configure the system, ask how something works, or just hand the AI a task and let it go. The chat interface isn't a simplified version of the app, it's a different way to use the full app.

For a new merchant who doesn't know where to start, this is the difference between leaving and staying. Instead of navigating a complex system they don't understand yet, they just describe their business. The AI handles the rest.

The development side: same infrastructure, completely different use case

Here's the part I didn't expect to matter as much as it does.

When I'm developing something new in Opencals, I can spin up an MCP server against the same documentation and API that the AI chat runs on. This means when I'm working on a new module or extending existing functionality, I have the full system context available without having to re-explain it to the AI every single session.

That sounds like a small thing. It isn't.

Before this, I'd spend the first 15–20 minutes of any AI-assisted development session re-establishing context: here's the data model, here's how this module works, here's what already exists. Now I don't have to. The AI already knows, because it's connected to the same source of truth the rest of the system uses.

My development velocity increased significantly. I haven't measured it precisely, but I'd estimate I'm shipping features 30-40% faster than before this was in place, purely from eliminated context overhead.

What I mean when I say "AI is infrastructure"

I've started thinking about this differently than I did 2 years ago.

AI used to feel like a feature you add. You pick a use case: chatbot, summary generator, search, whatever, integrate an LLM API, and ship it. It lives next to your real system.

That's not what I built. What I built is a system where AI is tightly bound to the actual code. It knows the data model. It knows the API surface. It knows the business rules. It can act as both a user-facing interface and a development accelerant because it's built on the same foundation as everything else.

I didn't realize this was the right architecture until I was most of the way through it. And I think I was lucky to be building it relatively early in Opencals' life: embedding this into a large, mature codebase after the fact would have been significantly harder. Starting close to the beginning meant the integration was natural instead of grafted on.

This is now how I'll approach every project going forward. Not "should we add AI?" but "where does AI live in the infrastructure from day one?"