--- title: "My Calendly Trial Expired. Building My Own Cost $11." description: "My scheduling tool wanted me to pay or rebuild my setup. Instead, I had Claude Code build a booking feature with license verification into Vuesion. It cost at most $11.54 and about two hours of my time. Here's what that number shows, and what it doesn't." canonical_url: "https://www.vuesion.dev/blog/my-calendly-trial-expired" --- > Index of every page on this site: [llms.txt](https://www.vuesion.dev/llms.txt) > **TL;DR:** When my Calendly trial expired, I built my own booking page instead: availability from my Google Calendar, Berlin public holidays, license verification through Lemon Squeezy, and confirmation emails with a calendar invite. Claude Code planned and implemented it for at most $11.54 in API costs. It took about two hours of my own time instead of the three to four days I would have needed alone. The price isn't the interesting part. What made it that cheap is, and so is the list of things I would still never build myself. Vuesion's Business license includes a 60-minute onboarding call. For that, I used Calendly. I set it up once and forgot about it. That's exactly what I want from a tool like that. Then the trial expired. It turned out I had been using a feature that was apparently premium. Nothing in the setup had told me. Now I had two options: pay, or rebuild the whole configuration with the free features. I didn't like either of them. And there was something Calendly could never do for me anyway. Anyone booking an onboarding call should have a valid Vuesion license. A generic scheduling tool has no way of checking that. So I decided to build it myself. ## Two years ago, I would have clicked through it I want to be honest about this part, because it's the reason this article exists. Two years ago, I wouldn't have built this. I would have reconfigured Calendly or looked for a free alternative. It would have taken me three or four days, and an existing tool already did most of what I needed. That trade was easy. What changed is how much a feature like this costs me. ## What I asked for I described what I wanted to Claude Code in a planning session: - A week view showing available slots, based on my Google Calendar - My availability: Monday to Thursday 12:00 to 13:00 and 17:00 to 19:00, Friday and Saturday 12:00 to 19:00, all in Berlin time - Berlin public holidays excluded - A form with the questions I need answered before an onboarding call - The license key verified with Lemon Squeezy - Confirmation emails in my own design, not Google's, with an iCal attachment The agent asked its questions, I answered them, and it wrote a plan. The result works like this. The page shows a week calendar where only free slots are clickable. Slots are 60 minutes, need 24 hours notice and are offered up to 28 days ahead. Google Calendar is the only source of truth. Nothing about availability is stored in my database, and the slot is checked again right before a booking is made. When someone books, the license is validated first. Then the Google event is created with a Meet link, and only after that is the license activated. If the activation fails, the event is deleted again. Everyone involved gets an email with an `.ics` file. What I deliberately left out: cancellation, rescheduling and reminders. If someone needs to move a call, they can reply to the email. ## The one thing I had to correct During planning, the agent wanted to write the week calendar from scratch. Vuesion already has one. I pointed it there, and it extended the existing component instead. That was the only correction I made in the entire feature. It's also the most important detail in this article, because everything that follows depends on it. A foundation only saves you work if the agent actually uses it. Sometimes it needs a nudge. ## The bill After planning, I started the implementation with a single command. The agent split the plan into seven tasks. For each task, a sub-agent implemented it, a separate reviewer checked it, the findings were fixed, and the fix was reviewed again. I didn't answer a single question or correct anything during that phase.
Cost (API prices) Time
Planning at most $1.20 about 30 minutes of mine
Implementation $10.34 42 minutes
Total at most $11.54
The planning number is an upper bound. That session also contained some unrelated cleanup work. I'm on the cheapest Claude plan, which costs €20 a month. The whole feature used about 6 to 7 percent of my weekly limit. What came out: - around 2,600 new lines of code, plus 645 lines added to existing files - roughly half of it tests - 82 new test cases, and all 4,256 tests in the project passing with 100% coverage - lint, type checks and both builds passing Then I spent an hour setting up Google and Lemon Squeezy, and half an hour testing the booking flow by hand, including every edge case I could think of. Everything worked. The only thing I changed afterwards was a design decision: the booking form now opens in a modal instead of appearing below the calendar. So my own time was about two hours. I estimate I would have needed three to four days to build the same thing myself. ## The bugs I wouldn't have found The part I find most interesting is not in the table above. The reviewer found problems that I never noticed: - A line break in a guest's email address could inject additional lines into the calendar file. - If the calendar ID was wrong or the calendar wasn't shared, Google would still answer successfully, just with an error inside the response. The calendar would have looked completely free. - One error response from Lemon Squeezy was treated as "license already used", and a missing field in the response was treated as an unlimited license. - If a confirmation email failed, the booking itself would have failed, even though the call was already in my calendar. Honestly, I wouldn't have anticipated most of these. Problems like that usually show up in production, after a real person runs into them. ## I don't read every line anymore This is probably the biggest change in how I work. When an agent builds a feature, I check two things. First, behavior. I go through the cases I have in my head and the edge cases I can come up with, and I test them by hand. Second, whether the code follows my standards. I skim it to see if it looks like the rest of the codebase, because I need to know that I'll find the right place when something breaks. Vuesion has strict rules about structure, naming, layering and tests. They rarely lead to code I can't follow. But checking is still better than assuming. What I no longer do is read every line. That only works because the standards exist. Without them, skimming would tell me nothing. ## The $11 feature took four days There's a catch in the number above. The agent didn't build a calendar component for this feature. It extended one that already existed. I built Vuesion's calendar components, day, week and month views and a Gantt chart, over two weekends. About four days in total. The week view alone took several of those days, mostly because of time zones. I had wanted to build components like that for a long time. Most of the freely available ones are old, and the good ones are expensive. Date components always felt like a bit of a mystery, as if only a few people had the skills to build them. I've never met a developer who built one, not even for fun. Claude Code helped a lot there too. Without it, I wouldn't have had the time. So the full story looks like this: agents gave me the time to build the foundation. Now the foundation makes the agents cheap. The $11 is just the last step. ## Where I draw the line None of this means I'm going to replace every tool I pay for. Free tools stay. If something works and costs nothing, I keep using it. I also keep paying for infrastructure. Building and running that myself would be far more effort and far more expensive. And I would never build what Lemon Squeezy or Stripe do. Payments come with so much legal work and regulation that I wouldn't touch them without serious funding. But tools like a scheduling page, a survey or a form? Those I'll build myself now, especially when they can live inside an application I'm already running and already paying for. My rule is simple: if hosting it myself would cost more than a free alternative that does most of the job, I use the free alternative. Otherwise I'd just be building another SaaS product, with its own domain and its own hosting, that suddenly has to pay for itself. ## Back to the trial My scheduling tool was supposed to be something I set up once and forget. Now it actually is. It lives in an app I already run, it checks something no external tool could check, and nobody can move one of its features behind a paywall. It cost me about two hours and eleven dollars. But it was only that cheap because of the four days I had spent on the foundation before. ## This is how I build Vuesion These aren't just ideas I write about. They're principles I've been building into Vuesion for more than eight years. [See how Vuesion works →](https://www.vuesion.dev/?utm_source=blog&utm_medium=article&utm_campaign=content&utm_content=my-calendly-trial-expired) ## Sitemap See the full [sitemap](https://www.vuesion.dev/sitemap.md) for all pages.