Opencals

Opencals is a booking platform for service businesses (think Shopify, but for selling services instead of products). We just made the storefront half of our API public, and instead of shipping it with only docs, we open-sourced a real app built on it.

Haar is a production Next.js 15 booking site for a salon: service catalog, real-time availability filtered by staff and location, single time slots and date ranges (for rentals), group bookings, multi-step Stripe checkout, and customer accounts with self-serve reschedule/cancel. MIT-licensed, deploys to Vercel in a click.

A few design decisions that might be interesting:

• Storefront-first API, not admin-first. We exposed the customer-facing surface (catalog, availability, cart, checkout, accounts) before the admin one, because the recurring ask was "let me build my own front end on your booking brain," which is a storefront problem.

• Availability is server-authoritative. The client never computes free slots or prevents double-booking — it asks the API and gets only currently-bookable slots. Killed a whole class of bugs.

• Typed SDK generated from OpenAPI. @opencals/storefront-sdk is auto-generated, so the SDK can't drift from the API.

• Config-as-rebrand. All salon-specific copy/branding is in one site-config.ts plus CSS variables, so the template is a starting point for any service vertical, not just salons.

Not open-sourcing the API itself (it's our hosted product), but the SDK and templates are open, and test keys are free with no card.

Demo: https://template-haar.vercel.app
Repo: https://github.com/letsopencals/template-haar
Docs: https://api.opencals.com/docs/storefront
SDK: https://www.npmjs.com/package/@opencals/storefront-sdk

Happy to go deep on the availability model, the checkout flow, or the GTM thinking behind giving templates away. Feedback very welcome, including the harsh kind.

I've been building Opencals (booking platform for service businesses): 150+ businesses on the platform, $0.99/booking pricing, all features built. The whole time I was doing what every IH post tells you to do for distribution – Quora, LinkedIn, Reddit, cold email, SEO. Slow grind. Some wins, mostly silence.

This week I realized something obvious that I'd somehow missed for the entire time I've been building.

Upwork isn't just a place to find freelance work. It's a public list of people who:

1. Have a written, scoped requirement for software you might already have built

2. Have a budget (they've already decided they'll pay)

3. Have decided they need a custom solution and are about to take the risky path (hiring a stranger)

That last point is the whole game.

I searched for "booking software" jobs on Upwork. I found around ~10 active postings, in one night, for custom booking systems. Salons, gyms, multi-location service shops, a tutoring marketplace. Each one had detailed requirements – number of staff, locations, payment integrations, calendar logic. The exact thing I've already built. With API, SDK, dashboard, admin panel, multi-location support, the works.

I wasn't going to bid as a freelancer. I bid as the founder of a product that already does 90% of what they wrote down.

The math from the customer's side

Hiring a freelancer to build custom booking software:

• $5k–$25k upfront

• 2–6 months of dev time

• High risk: you don't know if the freelancer is good, the spec changes mid-build, they disappear, the code is unmaintainable, you have no support after launch

• You own the code, but you also own all the bugs forever

Buying my product + implementing the missing 10%:

• A few hundred to a few thousand for the custom work

• Live in days, not months

• The core is already battle-tested by 150+ businesses

• I built it, I know it end-to-end, and I'm financially incentivized to keep it running

• They get all future improvements for free

When you frame it like that, the choice is pretty obvious to the customer. They didn't actually want a custom-built thing. They wanted their problem solved. They were going the custom route because they didn't know a product like mine existed.

The math from my side

Every "custom feature" I build for one of these clients goes into the core product. So:

• I get paid to build features I would have built anyway

• The features ship for all my other users

• I'm validating real demand with money on the table (not survey answers)

• The client becomes user #1 of the feature and helps me debug

This is the part that flipped my thinking. I was treating Upwork as a side hustle. But each gig is actually a funded user acquisition campaign for a feature my product needs.

Why I think this is underused

I think builders ignore Upwork and other freelance platforms because the framing is wrong. We think of it as "freelance work" – the thing you do when you're not building a product, or to pay rent. So when you're heads-down on your SaaS, Upwork doesn't enter the picture.

But if you flip the frame to "list of people who've written down their requirements and are about to spend money on a problem you've already solved," it's the most efficient lead source I've found. Better than Quora. Better than SEO. Better than cold email. These people are not skeptical leads – they are buyers who've already decided to buy something. The only question is what.

It also works the other direction. If you don't have a product yet and you're trying to figure out what to build, scanning Upwork for repeated job postings is a free, real-time, money-validated demand signal. Ten people posting jobs for the same custom thing this month means a market exists.

The honest caveats

• You need an actual product, not a half-built MVP. Customers are choosing you over a freelancer specifically because your thing is real and proven. If it's not, they'll just hire the freelancer.

• You have to be the founder/developer on the call. A salesperson can't credibly answer "can it do X? can we implement Y?" The leverage comes from you knowing the codebase well enough to commit to feasibility on the spot.

• You can't undercut on price. The pitch isn't "I'm cheaper than a freelancer." The pitch is "I'm dramatically less risk, and you're live in days instead of months."

• It's not infinite. There are only so many "build me X" jobs per week. But for a bootstrapped product that needs its first 50 paying users, it doesn't have to scale to infinity. It just has to fill the pipeline.

I wish I'd done from day one

If you're in the bootstrapping middle – product is real, traction is slow, you're not sure where the next user comes from – go open Upwork right now and search for the exact thing your product does. There's a non-zero chance someone is actively budgeting for it this week.

Don't bid as a freelancer. Bid as the founder of the product they didn't know existed.

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 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?"

I write code well. I build systems that hold up in production. I've been doing software development long enough to know what "reliable" means and how to get there.

What I'm still learning, and I'll be straight about this from the beginning - is how to run a business.

This is the story of Opencals. Year and a half in. Zero revenue. Still going.

It started with a friend's problem

In 2023, a friend of mine was planning on running a language school. Small operation, a few teachers, physical classroom sessions, online Zoom lessons, group bookings and individual ones. She needed a booking system.

I went looking for something on the Shopify App Store. There was nothing. Every booking app I found was built for the simplest possible case: one staff member, one service type, one location. The moment you added "multiple teachers with different schedules" or "student picks between physical and virtual," you were out of options.

This seemed like a completely normal business to me. A language school is not exotic. Why was nobody solving this?

I built it for her. And then I couldn't stop thinking about the bigger problem.

I built it. Then I built way too much.

The more I looked at service businesses, the more I saw the same pattern underneath all of them.

A salon needs staff scheduling and room management. A gym needs class capacity limits and recurring sessions. A car rental needs multi-day reservations. A tour operator needs group size management and fixed departure times. A clinic needs specific staff assignments and variable service durations.

They all share one actual hard problem: computing whether a booking is even possible right now, given staff availability, location hours, service duration, and capacity - at the same time. That's not a calendar question. It's an operations problem.

So I built Opencals to solve that. A single platform that could handle any service business - from a solo therapist taking simple appointments to a multi-location salon with ten stylists. I launched it on the Shopify App Store in July 2024.

The onboarding problem

Here’s where I made my first real business mistake.

I built something genuinely more capable than anything else in the Shopify App Store. But that also made it harder to set up. When your platform has to serve fifty different industries, it comes with a lot of configuration options.

I tried to solve this with a smart onboarding flow that guided users through all the required and optional steps. First version, second version, I thought it would fix the problem.

It didn’t. Most merchants skipped the onboarding entirely. They’d install the app, look at the screen, and either close it or message me. I ended up onboarding merchants manually, one by one, through chat and screen sharing.

So I built an AI setup wizard: describe your business, services, and availability, and the AI configures everything. It required building AI infrastructure into the project, which now improves onboarding, reduces support questions, and even helps me develop and fix issues.

At the same time, I was learning something more fundamental: most Shopify merchants don’t need a complex booking platform. The Shopify App Store is dominated by physical product sellers. Those who genuinely need service booking either don’t look for it there or need it to function independently of Shopify.

I turned off the ads and made a call.

The pivot to standalone

I rebuilt Opencals as a full standalone platform, with its own storefront, its own payment processing, its own order management, its own customer portal. The Shopify integration stayed (merchants can use both if they want), but the primary product is now independent.

The way I describe it: Shopify for service businesses. A full commerce platform - not just a scheduling widget.

The infrastructure I built also looks more interesting to me now than the SaaS product alone. The core can support an SDK and a proper API. Any developer who wants to build a custom booking experience for their client, custom frontend, custom integration, can use Opencals as the processing and payment layer underneath. That's where this is heading.

What I did wrong (and what I'd do again)

Everyone tells you: validate first, build later. Find customers before you write a line of code. Ship a bad MVP, find someone to pay for it, then improve.

I didn't do that. I built the product first. Not because I didn't hear the advice, I heard it constantly, but because doing business development was genuinely harder for me than writing software. So I did what I know.

My "MVP" is probably a finished product at this point.

The honest version: this wasn't optimal. I might have found my market faster with a scrappier version. But I also think a half-built product with no real differentiation wouldn't have kept me going through eighteen months with zero revenue. Having something I believe in is what keeps me working on it.

The conventional advice is right in principle. It was just harder for me to follow than to build.

Where I am now

Opencals has been running for eighteen months. Zero revenue. Just 150+ Shopify businesses using it. Entirely self-funded.

I'm not sharing the zero revenue number to be self-deprecating. I'm sharing it because it's the truth, and because I think it's context that matters: I spent eighteen months building something I believe is genuinely good, and now I'm starting the part I'm less experienced at - finding customers, building distribution, figuring out what "go to market" actually means in practice.

I built it to be reliable and low-maintenance. No bugs that keep me up at night, no fragile infrastructure that needs constant patching. The idea was that it could run lean, even run alone - because I built it that way from the beginning.

That part I got right, I think.

The business side is what I'm learning now. I'm going to be posting here as I figure it out.

If you're running a service business and frustrated with your booking setup, or if you're a developer building booking solutions for clients - I'd genuinely like to hear from you. Not to pitch. Just to understand the problem better.