MeetSynq is scheduling software from Cuanto Labs. It finds the window that works for both calendars and books it, with booking links, team round-robin, intake forms, Stripe payments and a white-label option for agencies.

Is MeetSynq built from scratch?

No. It is a fork of Cal.com, which is MIT licensed. The repository keeps an upstream remote and merges upstream changes, with the MeetSynq brand kept in a short list of files.

Which calendars does it sync?

Google Calendar, Outlook (Office 365) and Apple Calendar are the ones the product advertises. The inherited app store also contains CalDAV, Exchange, Zoho and other calendar integrations.

How does white-label work?

The app name, company name and email sender are read from environment variables per deployment, the brand colors and logo live in a theme file and public assets, and each deployment runs on a domain the client controls.

Engineering

How we built MeetSynq

By Eliran Yihye, Founder and Lead Engineer. October 12, 2026.

MeetSynq is scheduling software that finds the window that works for both calendars and books it. Guests open a booking link, pick from the time that is free on every connected calendar, and the invite lands on both sides with the video link attached. MeetSynq is built and run by Cuanto Labs, a software studio in Fort Lauderdale, Florida. Versions and prices below are read from the repo as of October 2026.

The problem

Scheduling looks simple until two calendars, three time zones and a team rule are involved. The hard parts are not the booking form. They are busy-time accuracy across providers, who gets the next booking, and not double-booking anyone. Building a calendar engine from nothing would have cost months, and open-source scheduling already solves that layer well. The useful work was elsewhere: packaging it as a product with its own name, pricing and marketing, and making it deployable under someone else's brand.

The second problem is branding. Agencies and software companies want to hand clients scheduling under their own name, with no vendor mark. So the goal was to adopt a proven engine, make it ours without forking it into something unmergeable, and make white-label a deployment setting instead of a rewrite.

Architecture

MeetSynq is a fork of Cal.com, which is MIT licensed, and the repository keeps an upstream remote for it. It is a Yarn 4 and Turbo monorepo: apps/web is a Next.js 16 App Router application on React 18 with Tailwind CSS 4, packages/trpc holds the tRPC routers, packages/prisma holds the schema and migrations on PostgreSQL, and packages/app-store holds the integrations. Calendar sync for Google, Outlook and Apple, Stripe payments and Zoom or Google Meet links are all apps in that store.

Request flow for a public booking page.

Deploys run through a deliberately small pipeline. The CI file in .woodpecker/ci.yml has a single step that asks Vercel to build the exact commit, because a full yarn installand type-check in this monorepo is too heavy for the CI runner's memory limit, and Vercel runs its own build and type-check anyway. Vercel's own git-push builds are switched off in apps/web/vercel.json, so that one step is the only trigger.

Data model and key pipelines

The Prisma schema defines 100 models as of October 2026. A handful carry the product: User, Team and Membership for people and groups; EventType for a bookable meeting; Host to attach people to it; Schedule and Availability for working hours; SelectedCalendar for which of a user's calendars block time; Credential for connected accounts; and Booking, Attendee and BookingReference for what was booked and where it lives in the external calendar. Team behavior is an enum, SchedulingType, with ROUND_ROBIN, COLLECTIVE and MANAGED. A rule in AGENTS.md forbids exposing the credential.key field in any query or response.

The booking pipeline is: read the host's schedule, subtract busy time from every selected calendar, offer the remaining slots in the guest's time zone, then write the event to the calendar and add the video link. The brand pipeline is separate. packages/lib/constants.ts reads NEXT_PUBLIC_APP_NAME and NEXT_PUBLIC_COMPANY_NAME, and the email sender name falls back to the app name, so a white-label deployment changes names by changing environment variables.

The marketing site is a small separate surface inside apps/web. The home, pricing, white-label and about pages share one MarketingShell component and one pricing-data.ts list, so the prices on the page and the offer range in the structured data come from the same source: marketing/seo.ts computes the low and high price from the tiers instead of repeating them. That module also builds the sitemap dates and llms.txt. A MARKETING_LASTMOD constant is bumped when page content changes, which keeps sitemap dates honest. meetsynq.cuantolabs.com is the canonical host for these pages, while booking links and sign-in stay on the web app URL.

Trade-offs

1. Fork upstream, confine the brand to a few files

Restyling upstream components directly would make every upstream merge a conflict. Instead AGENTS.md lists the only surfaces where branding may change: the theme file packages/config/theme/meetsynq.css, fonts in apps/web/app/layout.tsx, names and URLs in constants.ts, the marketing pages, public assets, and locale strings. The cost is discipline: after each upstream merge the locale brand substitutions have to be re-applied and the type-check re-run.

2. Cache public booking pages at the CDN

A public booking page renders the same for every anonymous visitor, so waking a serverless function and a scale-to-zero database for each view is waste. apps/web/vercel.json sets Vercel-CDN-Cache-Control: max-age=300, stale-while-revalidate=86400 on / and the public profile and event-type routes, only when there is no session cookie and no rescheduleUid, bookingUid or embed parameter. Translations ship as an immutable asset from app/api/i18n/[locale]/route.ts. The cost is staleness: an anonymous visitor can see a page up to five minutes old.

3. Branded hosts from Edge Config, not code

A branded host such as meet.<product>.comshould land on that product's event type. The first version used a hardcoded list in packages/lib/meetHosts.ts. It was replaced by an Edge Config key, meetHosts, read in apps/web/proxy.ts, which redirects / with a 307 to the mapped path. Adding a host no longer needs a deploy. The read is wrapped so a missing Edge Config variable degrades to no redirect instead of crashing the proxy.

What's next

The repo has no roadmap file. What it does show is that white-label deployments are stood up by hand today: the white-label page describes a brief, a deploy by Cuanto Labs and a launch. Nothing in the repository commits to automating that yet, and we would rather say so than invent a plan.

FAQ

What is MeetSynq?: MeetSynq is scheduling software from Cuanto Labs. It finds the window that works for both calendars and books it, with booking links, team round-robin, intake forms, Stripe payments and a white-label option for agencies.
Is MeetSynq built from scratch?: No. It is a fork of Cal.com, which is MIT licensed. The repository keeps an upstream remote and merges upstream changes, with the MeetSynq brand kept in a short list of files.
Which calendars does it sync?: Google Calendar, Outlook (Office 365) and Apple Calendar are the ones the product advertises. The inherited app store also contains CalDAV, Exchange, Zoho and other calendar integrations.
How does white-label work?: The app name, company name and email sender are read from environment variables per deployment, the brand colors and logo live in a theme file and public assets, and each deployment runs on a domain the client controls.

Written by Eliran Yihye. More about the studio on the About page.