One engineer, in Warsaw, building a booking infrastructure

I build Opencals on my own. There is no growth team behind this page: the NestJS services that run availability, the Next.js dashboard, the Shopify app, the public API and the site you are reading were all written by me.

Before Opencals I spent my career in product engineering, most recently as a senior engineer and tech lead at ReturnGo, an e-commerce returns platform, through to its acquisition by Global-e. The idea came from watching what service businesses were being handed instead: calendar tools that are over-engineered in the places nobody cares about and thin everywhere it matters. A generic booking page you cannot really change, a handful of settings, and features that either miss how the business actually runs or quietly break once it grows past one person in one location.

Service businesses are more inventive than that. A studio that rents rooms by the hour and also sells a six-week course. A clinic with four practitioners across two locations, with different rules at each. A rental shop with deposits and damage policies. None of them fit the shape of a generic scheduling page. They need a booking page that carries their brand rather than their vendor's, and software that bends around the way they already work instead of asking them to drop the parts that do not fit.

So Opencals is booking infrastructure for any service business, in any industry: every appointment is a real order with a payment and an invoice behind it. Shopify for services. And like Shopify, it is meant to be built on. The Storefront API is public and documented, the TypeScript SDK is on npm, and the Next.js storefront templates are MIT-licensed on GitHub, so developers and agencies can ship a fully custom booking site for a client on top of the same infrastructure instead of writing availability logic from scratch.