The 266-file monorepo covers the appointment loop
Across 266 files, SnagTime handles organizer accounts, workspaces, invitations, event types, public booking pages, and time-zone conversion. Availability can include weekly hours, date overrides, buffers, minimum notice, and booking windows. Invitees can answer custom questions, then confirm, reschedule, or cancel through recovery links. That is enough product surface for a consultant or small team to test a complete booking journey instead of assembling a calendar picker around a form.
The 1.8 MB checkout also includes custom workspace branding, Google Calendar free-busy checks and event creation, SMTP notifications, and optional test pricing. Payments deserve the qualifier: Stripe Checkout runs only in test mode, including webhook confirmation and refund handling. Live keys and live events are rejected by design. SnagTime can prove a paid-booking flow, but accepting real money would require separate implementation and an audit that this release does not claim.
What happened when we ran it
Our sandbox installed commit 1c95490 in 37 seconds, pulling 986 npm packages and occupying 1059 MB on disk. The environment was a fresh unprivileged Debian container with 3 CPUs, 8 GB of RAM, Node 22, and no secrets. The repository itself contained about 10,658 lines of source. Installation therefore worked, although the dependency footprint was much larger than the 1.8 MB checkout.
The production build failed with exit code 1 after 41 seconds. The log tail points to apps/web/src/server/db.ts at line 35 and links to Next.js's module-not-found message; the import path then reaches apps/web/src/server/auth/session.ts and apps/web/src/instrumentation.ts. The supplied tail does not identify a deeper cause, so the defensible finding is simple: the measured commit did not produce a Next.js production build in our clean container.
Vitest also exited 1 after 103 seconds: 92 tests passed and 104 failed out of 196 across 30 test files. The failures named capabilities, resilience, payment safety, event types, occupancy, sessions, and notifications. One notification case timed out after 5000 ms. Our run also found 1 moderate npm vulnerability, with 0 high and 0 critical findings. The checkout has a tests directory, one CI workflow, a Dockerfile, and npm workspaces, but those signals do not cancel the failed results.
The local demo and PostgreSQL 18 deployment are different jobs
Node.js 20.9 or newer is the documented entry point, with Node.js 24 named as the verified runtime. npm run setup creates an ignored local configuration and generates independent secrets, while npm run demo:free installs dependencies, prepares SQLite, seeds an organizer, and starts the development server. Local calendar, inbox, and payment adapters mean the first booking can be tried without Google, SMTP, Stripe, PostgreSQL, or hosting credentials. That is a thoughtful way to separate product evaluation from account setup.
PostgreSQL 18 is mandatory for the documented public architecture, which uses forced row-level security, verified database TLS, and separate migration, app, worker, and monitoring credentials. Operators must run a web container plus a continuously running worker behind HTTPS, create several independent application secrets, and rehearse encrypted backups. Google OAuth, a verified SMTP sender with SPF, DKIM, and DMARC, and Stripe test webhooks add human checkpoints. The guide says Vercel is unsupported out of the box and static hosting is incompatible.
Two open pull requests are the visible community activity
GitHub listed 331 stars, 113 forks, and 2 open items when checked; both open items were pull requests. The repository was created on August 27, 2026, main was last pushed on August 28, and outside pull requests arrived on August 29 and August 31. No release or tag exists. That is current activity, but it is only days of public history, too little evidence for upgrade discipline, maintainer response times, or long-lived production maintenance.
Open pull request 1 reports that the PostgreSQL production path could lose tenant context across an asynchronous boundary, hiding Google connection state and breaking an availability update. Its author supplied a fix and reported 39 focused tests passing on the branch, but the pull request remains open against commit 1c95490. We did not reproduce that deployment report. It is still a precise reason to test Google status, token refresh, availability saves, and tenant isolation on the exact production topology before inviting users.
Cal.diy and Easy!Appointments trade scope for longer histories
Cal.diy requires Node.js 18+ and PostgreSQL 13+, and it carries more scheduling surface from its Cal.com ancestry. Its own README now recommends personal, non-production self-hosting, so it is an alternative for feature exploration rather than an automatic production answer. Easy!Appointments takes the older PHP 8.2+ and MySQL route, with services, providers, working plans, Google Calendar sync, email, and multiple interface languages. That stack may fit conventional shared or managed servers better than SnagTime's worker and PostgreSQL 18 contract.
Our 41-second build failure and 104 failed tests outweigh SnagTime's clear documentation for any production decision today. The credential-free demo is still useful for inspecting its booking model, and the MIT license leaves room to repair or adapt it. We would keep that work in a local trial until main produces a clean build, the full 196-test suite passes in a fresh environment, and the reported production tenant-context fix is resolved. Real bookings should wait for those checks.