There is no Shopify for service businesses. I keep waiting for someone to prove me wrong.
There are hundreds of booking tools. Calendly is worth $3B. Mindbody has been around for 20 years. Fresha has 120,000 businesses on its platform.
And yet, there is no Shopify for service businesses. Not even close. I spent two years building one trying to figure out why.
Here's what I found.
The market splits into two camps that don't compete with each other
Horizontal schedulers (Calendly, Acuity, Setmore) are built for simple use cases. One person, one location, someone picks a time slot. Genuinely great at that - Calendly's UX is excellent, Setmore's free plan is generous. These tools solve a real problem well.
But they hit a wall fast. Add a second location. Add 4 staff members with different schedules and different availability per location. Try to book a room rental for a full day. They all break - not because the teams are bad at engineering, but because they were never architected for that question.
Vertical platforms (Mindbody, Fresha, Zenoti, SimplyBook) go the other direction. Deep features, built for specific industries: fitness studios, beauty salons, spa chains. They can handle the complexity. But they cost $139–499/month, they're locked to their vertical, and they've burned their users badly.
So what happens to a yoga studio with 2 locations and 6 instructors? Too complex for Calendly. Too expensive and too locked-in for Mindbody. They suffer through Calendly workarounds or pay $279/month for software that crashes on Safari.
This isn't a small gap. Estimated ~40% of the service business market. ~2M businesses in the US alone with no good fit.
Why hasn't anyone filled it?
That's the question I couldn't stop thinking about. My theory: horizontal tools think "calendar first" - they're solving a scheduling problem. Vertical platforms think "industry first" - they're building a product for a specific vertical with booking as one of many features.
Nobody thought "operations first." A service business doesn't just need a calendar. It needs to answer which staff can perform this service, at which location, on this day, given their specific schedule and this service's duration constraints? That's not a calendar question. It's an operations question. Treating it like one is why every horizontal tool breaks at scale.
The closest thing I've found is Cal.com - genuinely interesting infrastructure-first approach, and I respect what they're building. But they're going after developers and API consumers, individual staff members with calendar integrations, corporate teams. They're not trying to onboard a 3-location massage chain directly. No concept of a location, no operations model for a business with multiple staff and services. Different problem, different customer.
What I'm actually building
Opencals is an attempt to be the infrastructure layer for service businesses. Not a calendar tool. Multi-location, multi-staff, dynamic availability engine, cross-industry. Built to start simple and never force you to rebuild.
The pricing is different too: start with $0.99 per completed booking and 0 recurring cost, switch to a custom monthly plan once you get recurring traction. I watched small business owners paying $99/month in December when they had zero bookings. That felt wrong.
We're at 150+ businesses. It's early. Distribution is genuinely hard - service businesses are scattered, not in one place, and often mid-migration from something that's failing them. Every conversation I have though tells the same story: nothing fits, everything is a compromise.
And honestly, the hardest part isn't the product - it's the distribution question I haven't answered yet.
Do I go direct to service businesses and try to pull them in? Do I go through web development agencies and Shopify partners who already have these clients? Do I pick a single vertical - gyms, rental spaces, slot-based bookings, and own it before expanding? The vertical route feels safer but also feels like giving up on the "cross-industry infrastructure" idea before it's even proven.
Right now I'm trying all of it in parallel and watching what moves. That's probably a mistake, but I'd rather learn fast than bet everything on a hunch. The gap is real. What I haven't figured out is the cheapest door in.
Curious whether anyone has faced this specific choice - build horizontal infrastructure and go vertical first for distribution, or try to go horizontal from day one and accept the slower traction. What would you do?
the shift from “AI as a feature” to “AI as an interface” is probably the most interesting part here.
especially for complex products where onboarding breaks down — people don’t want to learn the system first, they just want to describe what they need.
feels like this works really well early on, but I’m curious how it holds up over time — do users eventually transition to the UI, or does the AI remain the primary way they interact with the product?
I guess you're referring to the previous post :)
I really don’t see the UI going away. It exists because it’s simply a more efficient way for humans to parse and interact with structured information. Sure, AI can compress everything into a long response, but people are lazy enough to read it - and prefer quick access to only what matters.
Where AI really shines is in handling the unknown. Right now its biggest value is reducing cognitive load, especially for new users who don’t yet understand the system. It lets them skip the learning curve and just describe what they want.
Over time though, once users are familiar, the UI usually becomes faster and more predictable than prompting. AI still plays a role in things like batch actions, clarifications, or discovering features are a better fit for it.
So it’s not one replacing the other, they complement each other. That pattern is already showing up across a lot of products.
AI isn’t deterministic and it’s relatively expensive for routine actions. Using it for repeatable tasks that a UI can handle more reliably doesn’t really make sense. If you have a calculator, you don’t ask AI what 2+2 is, but you might ask it how to approach a more complex problem.