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?
I think the “operations first” framing is the key insight here. For distribution, I’d go vertical first without making the product vertical-only. Pick the niche with the clearest pain, tailor the messaging/demo to them, and use that wedge to build trust and referrals. The infrastructure can stay horizontal underneath. My vote: horizontal product, vertical go-to-market.
Actually, I think you can easily use Shopify for service selling also, just create products with your service name and details with attaching service images.
Technically yes, but that only worked for the simple cases. The moment you add multiple staff with their own schedules, group appointments with capacity limits, or different service durations - Shopify apps had no way to handle that. You'd need a custom booking system on top.
Two years ago I was trying to build a site for a language school - multiple teachers, group sessions, flexible schedules, physical locations coming in. I looked everywhere. Nothing handled that level of complexity. So I built Opencals as Shopify app first.
And honestly, it's still the only app that does this and integrates natively into Shopify - including the customer side: viewing appointments, rescheduling, canceling, all self-serve.
What I learned though: most Shopify merchants don't need that (or they didn't know Shopify can handle it). They were using it for something simple - book a showroom visit, pick a time slot, done. For a lot of them, a custom form is honestly enough.
So yeah now whatever you need, something simple or full operational complexity, Opencals covers it. It's on Shopify as a native integration and also exists as a standalone platform. Same single platform either way, so every use case is there :)
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.
Yeah that makes a lot of sense.
I think your “operations first” framing is spot on — the product problem seems clear, but the distribution side feels like a completely different game.
From what I’ve seen, going horizontal early makes it really hard to communicate value, because every business sees a slightly different version of the problem.
The vertical-first approach doesn’t necessarily kill the broader vision — it just gives you a concrete story and faster feedback loops.
Otherwise you’re basically trying to sell “infrastructure” to people who don’t think in those terms.
Curious — have you seen any vertical where the pain is consistently strong enough that people actively look for alternatives?
The Shopify analogy breaks down because service businesses have a fundamentally different structure: the 'product' changes shape with every client, the delivery is relational, and there's no clean inventory to manage. Shopify works because commerce is repeatable. Services aren't.
The tools that have tried (HoneyBook, Dubsado, etc.) solve the contracts-and-invoicing layer but leave the operational layer - who's at what stage, what's at risk, what needs to happen this week - completely unaddressed. You end up with a CRM for billing and a mental map for everything else.
What actually works for service solopreneurs is a lightweight system that treats each client engagement as a project with its own pipeline stage, linked to revenue tracking and a weekly review. Not a SaaS - more like a well-designed Notion workspace that's actually built around service delivery logic rather than product sales logic.
I've been building exactly this as a Solopreneur OS: 6 linked databases (CRM, client portal, projects, revenue, decisions, weekly review) that give service founders the operational view Shopify gave product founders. The gap is real and the reason no SaaS fills it is that every service business is just different enough that software can't pre-configure it.