by Mateusz Sowa
Build Your Own Calendly with One Agent Skill
In early October a software engineer, Brandon Thomas, published ArtCraft: free, open-source rebuilds of seven Adobe apps, Photoshop, Illustrator, Premiere, Lightroom, Acrobat, After Effects and InDesign, written from scratch in Rust with Claude (PetaPixel). Five days later he followed with Word, Excel and PowerPoint, as WordCraft, GridCraft and DeckCraft (PetaPixel). An AutoCAD clone and an audio mixer are announced next.
The apps are early. Reviewers call them alpha, rough in places and not ready for client work. But the direction is clear: rebuilding software that took decades now takes weeks, and the subscription you pay every month is starting to look like a choice.
So we are making one. Today we publish calendar-scheduling-links, an Agent Skill that lets anyone build their own Calendly: booking pages, availability, calendar sync, invitations, reminders and self-service reschedule, on Next.js on Vercel, with Supabase or Firestore, under your own accounts. You own the code. You extend it yourself, with your agent, or with us.
This post covers why scheduling, what is in the skill, why it beats reverse engineering, and a tutorial that takes you from an empty folder to a live booking page.
Why scheduling links
Calendly is very good at what it does. Its free plan covers one event type, and for many people that is all they will ever need. If that is you, stay with it.
The cost starts with the team. Calendly charges per seat, every month: from $10 a seat on Standard and $16 on Teams, and round robin is on Teams only (Calendly pricing, checked 15 October 2026). Ten people on Teams pay at least $1,920 a year, for meeting links on someone else's domain, sending someone else's emails, and doing what the vendor's roadmap allows.
A scheduling link is also the ideal size for owning. It is small enough to understand end to end. It sits at the front of your sales, support and onboarding. And once it is yours, the next feature is a prompt away: a question that routes leads to the right person, a payment before the call, a note to your CRM after it. We wrote more about that moment in When Calendly is no longer enough.
What is in the skill
A scheduling page looks simple: a calendar, some free times, a button. The hard part is everything around the button: two people picking the same time, a calendar that changed a minute ago, the night the clocks go forward, a meeting that moved while its reminder still goes out for the old time. The skill carries the core with those cases handled.
| Area | What your agent builds |
|---|---|
| Event types | One-on-one and group sessions with seats, durations, slot steps, custom questions |
| Availability | Weekly hours per day, date overrides and days off, any IANA time zone |
| Rules | Buffers before and after, minimum notice, daily limits, a rolling booking window |
| Calendars | Google Calendar and Microsoft 365 or Outlook: busy time hidden, bookings written in, Meet or Teams links |
| Emails | Confirmation with a calendar invite, a note to the host, reminders a day and an hour before |
| Self-service | Reschedule and cancel from a private link, with the invite in the guest's calendar updated, not duplicated |
| Integrations | Signed webhooks for created, rescheduled and cancelled bookings, and an embed for any website |
| Data | Supabase by default, Firestore supported, every table server-only |
Five rules hold it together, and the skill makes the agent keep them. The booking is checked by the same function that listed the free times. Every booking is written under a lock per host, with a database constraint that refuses a double booking even if something else goes wrong. Emails, calendar writes, reminders and webhooks are queued in the same transaction as the booking and retried until they go through. Times are stored as instants and converted with an explicit time zone. And every link and token is either hashed, encrypted or signed.
It is not the whole of Calendly. Round robin, collective events, routing forms and payments are not built in yet. The skill describes how each one attaches to the core, and which of our other skills covers it, so your agent extends the core instead of working around it.
Why not just reverse engineer it
The same week, a tool called Reverse Engineer Anything went viral for helping agents pull apart compiled software. Fireship's The Code Report on 12 October showed the whole route: decompile a desktop app with Ghidra, read back C-like pseudocode, then hand it to a coding agent to rewrite in Rust. It works, in the sense that you get code. The host's verdict on the ArtCraft video editor he tried was that it was close to unusable: laggy playback, weaker transitions, the cracks visible within minutes.
That is what reverse engineering gives you: code that does roughly what the original does, without the reasons it does it. For a scheduling product it is worse, because a web service like Calendly has no binary on your machine to decompile. All you can observe is its pages and its network traffic, and an agent guessing a booking engine from the outside pays for every guess twice: once in tokens, once in bugs.
Fewer tokens
Reverse engineering spends most of its budget before a single line of your product exists. The agent reads decompiled output or captured traffic, reconstructs the behaviour, writes a version, runs it, finds what it got wrong, and goes round again. Every round re-reads code and logs, and the rounds stop when the visible behaviour looks right, not when the edge cases are covered.
A skill turns that around. The agent reads a short entry file, about 3,000 tokens, and then only the reference for the step it is on: the slot engine when it builds slots, the migration when it builds the database. The largest single reference is around 6,000 tokens. The decisions in them are already made, so the agent writes the module once, from a design, instead of discovering the design by trial.
| Reverse engineering | The skill | |
|---|---|---|
| What the agent reads first | Decompiled code or captured traffic, as much as it takes | A 3,000-token entry file with the architecture and the rules |
| How it learns the edge cases | By running, failing and reading the failure | They are written down, with the test that checks each one |
| When it stops | When it looks right on the happy path | When the shipped tests pass |
| What your tokens buy | A reconstruction of someone else's product | Your product, on a core that is already designed |
Fewer bugs
The bugs that matter in scheduling do not show on the happy path. They show on the second booking in the same second, on the night the clocks change, and three weeks later when a reminder fires. Pseudocode does not record them, and a rewrite from observed behaviour cannot see them at all. These are the failure classes the skill is written against, and how it handles each:
| Failure | What a reconstruction tends to do | What the skill ships |
|---|---|---|
| Two people book the same time in the same second | Check, then write: both succeed | One lock per host and a database constraint that refuses the second; tested with four simultaneous requests on Supabase and the Firestore emulator |
| The clocks go forward overnight | Add 24 hours to step days, and skip a whole day of slots | Walks local calendar dates; tested across both clock changes and a UTC+5:45 zone |
| A meeting is moved | A new calendar event and a new invitation next to the old ones | The same event and the same invitation, updated in place; tested on a reschedule chain |
| A reminder after a reschedule or cancel | Sent for the old time | Deleted with the change and re-checked before sending; tested with a stale reminder that must stay silent |
| An email or webhook provider is down | The rest of the booking flow stops, or the message is lost | Every side effect is a queued job, retried with backoff on its own |
| A cancel link | The booking id is the key, so anyone who sees it can cancel | A signed token, stored only as a hash |
| Connecting a calendar | An unsigned callback that lets one account bind to another | Signed state tied to the signed-in host, PKCE, tokens encrypted at rest |
| The host marks time as free or declines a meeting | Still blocks the slot | Free, cancelled and declined events stay bookable; tested against both providers' formats |
They are invisible until they cost someone a meeting, and the way to know them is to have built and run a booking engine for years, which is what we do. The skill is written from the booking engine we have run in production, with each fix recorded in its provenance file and 47 tests that hold the rules. Before release, the code in the skill itself was compiled, tested and run: a full booking, reschedule and cancel over HTTP against a local Supabase database.
Your agent's tokens go into your product, not into rediscovering ours.
Tutorial: your own scheduling links in an afternoon
You need Node.js, a Vercel account, a Supabase project and a coding agent: Claude Code, Codex CLI or Gemini CLI. Google and Microsoft calendar sync is optional; the rest works without it.
1. Create the app and install the skill.
npx create-next-app@latest my-scheduling --ts --app --eslint
cd my-scheduling
npx skills add timerise-ai/calendar-scheduling-links2. Connect Supabase. Link the project to Vercel and add Supabase from the Vercel Marketplace, which sets the Supabase environment variables for you. Then pull them locally.
vercel link
vercel integration add supabase
vercel env pull .env.localFor local work, supabase start gives you a full stack on your machine instead.
3. Ask your agent to build it. Start the agent in the folder and paste:
Add Calendly-style booking links to this Next.js app on Supabase: hosts set their weekly availability and event types, visitors book a free time on a public page, both get an e-mail with a calendar invite, and the visitor can reschedule or cancel from a link in that e-mail.The agent reads the skill, maps it onto your app, and builds the slot engine, the migration, the booking service, the jobs, the routes and the pages. It finishes with the list of what you still have to set up.
4. Apply the migration.
supabase link
supabase db push5. Set the secrets. Generate them once and add them to Vercel for Production and Preview.
openssl rand -base64 32 # SCHEDULING_ENCRYPTION_KEY
openssl rand -base64 48 # SCHEDULING_TOKEN_SECRET
openssl rand -base64 24 # CRON_SECRET
vercel env add SCHEDULING_ENCRYPTION_KEYDo the same for SCHEDULING_TOKEN_SECRET, CRON_SECRET, APP_URL (your public address), and your email provider's key. The skill ships a SendGrid adapter; any provider fits behind the same interface.
6. Schedule the background work. One route sends queued emails, retries failures, renews calendar subscriptions and re-reads calendars. On Vercel Pro, run it every five minutes from vercel.ts. On Hobby, where crons run once a day, the skill schedules it from Supabase with pg_cron instead.
7. Connect calendars, if you want them. Create a Google OAuth client and a Microsoft Entra app, add the redirect addresses the skill lists, and put the client ids and secrets in the environment. Google asks you to verify the app before anyone outside your test users can connect a calendar, so start that early.
8. Deploy and embed.
vercel deploy --prodCreate your host profile, a schedule and an event type, open /your-handle/intro in a private window and book yourself. Check the email, the invite, the reschedule link and the cancel link. Then put the page on any website:
<div data-scheduling-url="https://book.example.com/your-handle/intro"></div>
<script src="https://book.example.com/scheduling-embed.js" async></script>That is a working core you own. From here, it grows with you.
Extending it
There are three ways, and you can mix them.
With our other skills. bookable-events adds paid sessions with Stripe Checkout and deposits that stop no-shows. stripe-connect-subscriptions turns it into a marketplace where providers get paid. slack-ai-bot tells your team about new bookings and answers questions about them. booking-kiosk puts a walk-up booking screen in your venue on the same core. visit-logger shows you who opened a booking link, and invoicing bills paid sessions.
With your agent. The skill's extensions file lists what a team scheduling product adds, round robin, collective events, routing forms, polls, SMS reminders, with the rules each one must keep and a prompt to start from. For example:
Add round robin event types: an event type can list several hosts; slots are the union of their free slots, and a booking goes to the eligible host with the fewest bookings that week. Keep the per-host lock and the overlap constraint.With us. If you would rather have it built, or you need more than meetings, rooms and equipment, approvals, rules that no setting covers, send us a brief. We build it on the same skill into a system you own, for a fixed price. And if you build these for clients, Timerise Builders is our partner program for exactly that.
What to know before you switch
Owning it means running it. You keep the secrets, watch the job queue and renew the Microsoft client secret before it expires. The skill's operations guide lists what to watch. Google's verification of calendar access takes days to weeks. Email deliverability is yours: use a provider and a domain you trust. And for one person with one event type, Calendly's free plan is still the easier answer.
For a team that pays per seat, wants its own domain and data, or needs the next feature on its own schedule, the core is now a free download and an afternoon of work.
Get the skill: timerise.ai/skills/calendar-scheduling-links, or straight from GitHub.
Calendly is a trademark of Calendly LLC. Timerise is not affiliated with Calendly. Adobe, Microsoft and the other product names are trademarks of their owners.