Someday hosts a booking page inside your own Google account

The backend is a spreadsheet script, not a server

Someday is described as a free to host calendar availability picker and an open source cal.com and Calendly alternative built on Google Apps Script for Gmail users, with React, TypeScript, Shadcn/UI and Vite on the front end.

The hosting model is the whole idea. Instead of a server that you operate, the backend is an Apps Script web app that you deploy into your own Google account, and the project says hosting is free via your Google account. The deployment tool is clasp, the command line client for Apps Script.

That choice has consequences in both directions, and the project is clear about the good ones. The script integrates with Gmail by construction, because it is running inside Google and reading a Google calendar, and the privacy claim is specific rather than rhetorical: no data sharing beyond Google to third party apps. A person who books a slot gives you a name, an email, a phone number and an optional note, and nothing leaves the Google account.

The constraint that follows is equally concrete. The thing being scheduled is a Google Calendar, and the person using it is a Gmail user with a Google account. The booking page is a front end to that, not an independent scheduling service that happens to read a calendar.

There is a demo at someday-demo.vercel.app, and the README is explicit that its endpoints are mocked, which is the fastest way to see what the interface does before touching a real calendar.

Availability is five constants in one file

The customisation surface is a single TypeScript file, backend/src/app.ts, and the README shows the whole shape of it.

// backend/src/app.ts
const CALENDAR = "primary";
const TIME_ZONE = "America/New_York";
const WORKDAYS = [1, 2, 3, 4, 5];
const WORKHOURS = {
  start: 9,
  end: 13,
};
const TIMESLOT_DURATION = 30;

That is the entire configuration. The calendar to read, the time zone to compute slots in, the days of the week you work, the hours within those days, and the length of a booking slot.

The rest of the feature list follows from those five values. Customisable work hours, with the slot generator producing times that fit your schedule. A simple booking process where the user selects a date and a time slot and fills in a form with their name, email, phone and an optional note.

The CALENDAR constant has more behind it than the name suggests. By default the script uses your primary calendar, and to use other calendars they have to be added to your Google Calendar with appropriate permissions, and the script needs at least read access to the calendar you specify. If you want several calendars, that is a different mechanism: a Script Property named CALENDARS holding a comma separated list of calendar IDs, added through the Apps Script editor under Project Settings, with the steps spelled out in the README.

The design choice to notice is that availability is a filter on your calendar rather than a separate schedule. A slot appears because the calendar is free, and that is what keeps a booking page from lying to the person who receives the invitation.

Deployment is clasp, and the authorisation step is the awkward part

The install instructions are long, and the reason is that deploying an Apps Script is not a single command, and the first authorisation is manual by design.

The setup starts with clasp itself, installed globally with npm.

npm install -g @google/clasp@^2.5.0

Then you log in, and if configuration files conflict with what you are doing you remove the existing .clasp.json.

clasp login

rm .clasp.json

Before anything works, the Apps Script API has to be enabled in the Google account settings, and the README asks you to wait a few minutes for the change to propagate, which is a good description of what that step actually involves.

Then the project is created as a web app and deployed.

clasp create --type webapp

npm run deploy

Visiting the URL afterwards shows the message Authorization is required to perform that action, and that is expected rather than a failure. The authorisation itself has to be done from the script editor: run clasp open, go to dist/app.gs, select fetchAvailability from the drop down and hit run, then work through the permission modal by choosing your account, opening the advanced options, going to the unsafe option for your script and clicking Allow. The README says to refresh the editor and run the function again, at which point it should complete without issue.

The cheat sheet at the end of the README condenses the operations: npm run deploy to build and deploy, npm run build to build only, undeployall.sh to undeploy all versions of the script, deployments.sh to list the web URLs of the deployments, and clasp open to open the editor.

The iframe trick removes the Google banner from the booking page

There is one piece of Google in the interface that the project does not want, and there is a documented way around it.

Google Apps Script puts a banner on the deployed app saying that this application was created by a Google Apps Script user. To remove it, the README says you can host the HTML file yourself and embed the script as an iframe, using the hosted-iframe-example.html file. GitHub Pages is suggested as a good option for hosting, and you add your script URL to the src attribute of the iframe.

That is a small workaround with a large consequence, which is worth stating plainly. The booking page now lives in two places, the HTML you host and the script you deployed, and they are only connected by a URL in the iframe. If the script is redeployed or the URL changes, the hosted page has to be updated to match.

It also moves the privacy story. The README's claim is that no data is shared beyond Google to third party apps, and an iframe hosted on GitHub Pages does not change what the script does with a booking, but it does mean a third party host is now in the path of the page itself.

For a small project that is a reasonable trade for removing a banner, and for a project that cares about the privacy claim it is a decision to make deliberately rather than by default.

The frontend is a separate app with a mock mode

The repository is split into backend/ and frontend/ directories, and the frontend is a normal web application rather than something that lives inside the Apps Script project.

The development instructions are three commands.

cd ./frontend
npm install
npm run dev

The important detail is the one in the parenthesis. The dummy data is generated on the fly using the generateDummyData function, around line 42 in frontend/hooks/useGoogleTimeSlots.ts, which means the frontend can be developed and demonstrated without a Google account, a deployed script or a real calendar. The hook is named after the slot source, so the mock stands in for the same interface the real backend fills.

That is a much better arrangement than it sounds, because the hard part of a project like this is not the interface, it is the calendar permission dance. Keeping the interface runnable against generated data means a change to the slot grid or the booking form can be made and reviewed without touching Google at all.

The root package.json shows how the two halves meet. The build script runs ./build.sh, the deploy script runs ./deploy.sh, and there is a separate build:demo script that builds only the frontend demo, which is what the Vercel deployment is serving. The backend has its own workspace package, since the dev script for the API is run through yarn workspace @radishes/api in the related project, and in this one the same split appears as separate directories with their own tooling.

What the project does not cover, and what the test script says

The features that are not there are as informative as the ones that are, and the README is reasonably forthcoming about the gaps.

There is no account system beyond the Google one, no team scheduling, no payment, no reminder emails and no calendar write-back that the documentation describes. The booking is a form and a calendar read, and everything else in a scheduling product is somebody else's problem or a future task.

The test story is thin to the point of being honest. The test script in package.json is the same placeholder pattern you see in a freshly generated package, and it fails on purpose.

"test": "echo \"Error: no test specified\" && exit 1"

The root package is marked private, its version is 1.0.0, and its only runtime dependency is @date-fns/tz, which is the time zone helper the slot computation needs. The build and deploy tooling is shell based, with build.sh, deploy.sh, deployments.sh and undeployall.sh at the root, and there is an appsscript.json for the script side and a .claspignore for what should not be pushed to Apps Script.

For maintenance, the project is MIT licensed, it is not archived, and the last push was on 2026-07-20. The repository publishes no GitHub releases, so the state of the project is the state of the master branch, and the scripts that deploy versions of the script are how you keep track of what is live.

Editorial conclusion

Someday fits a Gmail user who wants a booking page for their own availability, who is willing to live inside the Google Apps Script deployment model, and who would rather not run a server. It is the wrong tool if you need multiple staff calendars, a booking flow that is not tied to a Google account, or a product with a service level agreement behind it. Verify first that the Apps Script API is enabled and that the authorisation flow works for your account, because the script needs at least read access to the calendar it reads, and note that the package test script exits with an error because no tests are configured.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. Project website
4. rbbydotdev/someday on GitHub
5. README