Opencals is built by an engineer. Here's the story.

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.