20:34Nate Herk | AI Automation · Review
Claude Code vs. Codex: An 8-Site Head-to-Head Design Test
Same prompts, same brand kits, two coding agents — one landing page built by each, eight times over, scored on design and on the bill.
August 26thThe argument in one line.
An AI coding agent can clone the core functionality of a billion-dollar SaaS product from a handful of upfront prompts, but the result is only free at the point of use, the actual build consumed about $15,000 in inference and days of autonomous agent runtime.
Read if. Skip if.
READ IF YOU ARE…
- You pay monthly for a scheduling tool like Calendly or cal.com and want to know if a self-hosted, agent-built alternative is realistic.
- You want to see what a multi-day, multi-agent autonomous build actually looks like end to end, not just a single demo prompt.
- You're trying to estimate what an AI-built internal tool really costs once you count inference, not just the subscription price you'd otherwise pay.
- You're comparing Codex and Claude Code on a real, cost-tracked project rather than marketing claims.
SKIP IF…
- You want a step-by-step coding tutorial, this is a build recap and product demo, not a prompt-by-prompt walkthrough.
- You need production-grade SaaS advice, the creator is explicit that this is a personal-use clone, not something built to scale to paying customers.
The full version, fast.
The creator used Codex to clone Calendly's core functionality into a free, self-hosted scheduler called SnagTime, complete with live Google Calendar sync, custom event types, and Stripe-powered paid bookings. The build ran on one large upfront prompt broken into four phases (research, plan, build, test), with a build-test loop where swarms of sub-agents clicked through the app hunting bugs before any human involvement. The catch: it took 5 days 5 hours of actual agent runtime, 334 aggregate agent-hours across 76 sub-agents, and roughly $15,000 in inference, nearly all absorbed by an existing $200/month Codex plan. It isn't free to maintain either, expect to keep prompting monthly for bugs and features if you actually adopt it.
Free for members
Chat with this breakdown — free.
Sign in and you get 23 free chat messages on us — ask for the hook, quote a framework, find the exact transcript moment, generate a markdown action plan. Bring your own key when you want unlimited.
Create a free account →Where the time goes.
00:00 – 00:25
01 · I Cloned Calendly (cold open)
Valuation stakes for Calendly ($3B) and cal.com (~$150M) set up the claim that the core functionality was cloned in one week for free.
00:25 – 01:55
02 · SnagTime App Tour
Walkthrough of the SnagTime dashboard, overview stats, workspace settings, branding, and the event types list.
01:55 – 02:12
03 · FREE Install
Points viewers to a free Skool community holding the full setup guide, since the demo is running on localhost.
02:12 – 03:52
04 · Live Booking & Calendar Sync
Books a slot through the public booking link and shows it syncing live against the real connected Google Calendar in both directions.
03:52 – 06:32
05 · Custom Events & Stripe Payments
Edits an event type's availability and questions, then runs a full paid booking through a sandboxed Stripe checkout, plus a UX bug the testing agents missed.
06:32 – 07:17
06 · Owning the Software Layer
Availability rules (weekly hours, overrides, time off) and the argument that owning the code turns feature requests into prompts instead of vendor tickets.
07:17 – 10:29
07 · Five Prompts Behind the Build
Recaps the four-phase slash-goal prompt (research, plan, build, test), the rebrand away from the agent's auto-generated name, and the follow-up passes for UI redesign and lag fixes.
10:29 – 13:59
08 · The Reality of AI-Built
Reveals the actual numbers, 5 days 5 hours of runtime, 334 aggregate agent-hours, 76 sub-agents, 32.1B input / 47.4M output tokens, about $14,983 in inference, and what maxing a $200/month Codex plan buys versus Claude Code.
Lines worth screenshotting.
- A working Calendly clone, complete with live calendar sync, custom event types, and Stripe payments, was built from a single four-phase upfront prompt plus four follow-up correction prompts.
- The build ran for 5 days 5 hours of wall-clock agent activity but logged 334 aggregate agent-hours, because many sub-agents worked in parallel.
- 76 unique sub-agents were spun up over the project, though the creator estimates true delegation events exceeded 300 once repeated testing and verification swarms are counted.
- Total inference across the build was 32.1 billion input tokens and 47.4 million output tokens, pricing out to roughly $14,983.
- Almost none of the $15,000 inference cost was paid out of pocket, it was absorbed by an existing $200/month Codex subscription, with only about $150 spilling into pay-as-you-go usage.
- Maxing out a $200/month Codex plan yields roughly $14,000 in modeled inference value, compared to roughly $8,000 for maxing out an equivalent $200/month Claude Code plan.
- Autonomous testing swarms of roughly 50 agents clicking through sign-up, admin, and booking flows caught functional bugs, but missed a UX assumption: users expect an entire progress bar to be clickable, not just its small arrow icons.
- The first agent-built version looked visibly 'vibe coded', down to an unwanted auto-generated product name (Tempo Cove), and needed a dedicated rebrand and redesign pass before it felt usable.
- A second round of prompting was needed purely for performance, the initial build had laggy typing and cursor responsiveness that the testing agents never flagged as a problem.
- Owning the code changes the relationship to future bugs and feature requests, they stop being support tickets to a vendor and become prompts to the coding agent you already have.
- A free, agent-built internal tool is not maintenance-free, the creator expects to keep sending prompts monthly to fix bugs and add features as they surface.
- There's a real gap between building a tool for internal, single-team use and building something meant to scale to tens of thousands of dollars a month in paying customers, more bugs, more feature requests, more ownership required either way.
A 'free' AI-built app still cost about $15,000 in inference
WHAT TO LEARN
The build looked like five prompts and a free result, but it actually took five days of wall-clock agent time, 334 aggregate agent-hours, and roughly $15,000 in inference, almost all of it absorbed by an existing monthly plan rather than paid separately.
02SnagTime App Tour
- The rebuilt scheduler mirrors Calendly's actual feature surface, a dashboard, event types, bookings list, and workspace settings for branding, team roles, and permissions.
- Matching an incumbent's feature surface like-for-like is a fast way to validate that an agent-built clone covers what people already expect, instead of guessing at scope.
04Live Booking & Calendar Sync
- The booking page reads and writes directly against the connected Google Calendar, so blocking a slot on the real calendar makes it vanish from the public booking link almost immediately.
- Demonstrating live two-way calendar sync, not just a static booking form, is what makes a scheduling clone credible as a Calendly replacement rather than a toy.
05Custom Events & Stripe Payments
- Each event type carries its own duration, availability rules, questions, and price, and switching an event from free to paid is essentially a toggle plus a live Stripe key.
- Paid bookings route through a real Stripe checkout, so the clone can charge for consultations the same way the incumbent tool does, not just schedule free calls.
- The one bug fully autonomous testing agents missed was a UX assumption, users expect an entire progress bar to be clickable, not just its small arrow icons, and it took a human walkthrough to catch it.
06Owning the Software Layer
- Once the code is yours, a feature request stops being a support ticket to a vendor and becomes a prompt: ask the coding agent to add the functionality directly into the app you already own.
- Availability rules like weekly hours, date overrides, and time off are table stakes the clone had to reproduce before it could realistically replace a Calendly workflow.
07Five Prompts Behind the Build
- The whole build started from one large upfront prompt structured into four phases: research the competitors, plan the feature set, build it, and test it in a loop.
- After the first build looked visibly 'vibe coded,' down to an unwanted auto-generated app name, the creator spent additional prompts on a rebrand, a UI redesign, and fixes for laggy typing and cursor response.
- The build-test loop ran dozens of sub-agents acting as users clicking through sign-up, admin, and event-creation flows to hunt bugs before a human ever opened the app.
08The Reality of AI-Built
- The build ran for 5 days and 5 hours of actual wall-clock agent activity, but logged 334 aggregate hours because many sub-agents worked in parallel.
- 76 unique sub-agents were spun up, though the creator estimates true delegation events were closer to 300+ once repeated testing and verification swarms are counted.
- Total inference, 32.1 billion input tokens and 47.4 million output tokens, priced out to roughly $14,983, nearly all of it absorbed by an existing $200/month plan rather than paid out of pocket.
- The app is not actually free to maintain, the creator expects to keep sending a few prompts a month to fix bugs and add features, calling that cheaper than a subscription only if you're willing to own the upkeep.
Terms worth knowing.
- Slash-goal prompt
- A single upfront prompt that hands an AI coding agent a full multi-phase mandate, in this case research, plan, build, and test, instead of a narrow one-off instruction.
- Agentic testing loop
- An autonomous cycle where coding agents build a feature, spin up dozens of sub-agents to click through the app hunting for bugs, fix what they find, and repeat without a human in the loop.
- Sub-agent
- A secondary AI agent spawned by a primary coding agent to handle one piece of work, such as testing a single user flow, then reporting back to the main task.
- Aggregate agent-hours
- The total compute time logged across every agent and sub-agent running on a project, including parallel work, which can be many times higher than the wall-clock time the project actually took.
Things they pointed at.
09:45toolStripe (sandbox test checkout)
13:00toolOpenAI Codex CLI
13:00toolClaude Code
Lines you could clip.
12:40
“This was a $15,000 project.”
07:06
“You own the software layer.”
09:33
“It's not just as simple as a few prompts, and you now have something that can stand the test of time.”
Word for word.
Read-along
Don't just watch it. Burn it in.
See every word as it's spoken — crank it to 2× and still catch all of it. The same dual-channel trick behind Amazon's Kindle + Audible.
metaphor
So I just built a clone of Calendly, and it's completely free for me to run. Calendly has an estimated valuation of $3,000,000,000, and competitors like cal.com have a valuation of around a 150,000,000 and have raised tens of millions of dollars.
But in one week, I was able to clone the core functionality of it with just a few prompts, and now it's free for me. So in this video, I'm gonna show you guys what I built, give it away for free, show you how you can get set up for yourself, and talk about exactly how much this cost me to actually build. So let's not waste any time and just get straight into today's video.
Alright. So just gonna jump right in. This is called snag time.
You can see that we have to sign in. I've already created an account, so I'm just gonna go ahead and log in. And now we are at the home screen.
You can see we have an overview. We have my branding. This is my workspace called UpItAI.
I can see my upcoming bookings. I can see how many I've had this month.
I can see how many hours I've booked and my published links, so how many different event types I have. I can see all of my upcoming bookings right here, and I could go in, find some more details. I could also reschedule or cancel.
So if you guys have used Calendly or stuff like cal.com before, it's very similar. You're getting the same functionality. I can come down here to my settings, and I can change my workspace, my password, my profile photo.
I can invite other members and have different, like, permissions, whether they're a member or an admin, and I can set up my workspace image, colors, descriptions, stuff like that.
So what I thought I'd show you real quick is what is an event type and how does that actually work? So if I go to my event types, you can see that I have a revenue strategy session. I have this test, and all of these were pretty much made during testing.
I've made a few of these myself, like the paid scoping session. Yes. I've connected Stripe so you can actually book in paid calls, and then we've got this regular strategy call.
So let me first just do a simple one real quick. And by the way, all of these say local host, meaning right now I'm running all of this locally. So in order to actually get this up and running so you can send, you know, links to clients and have them book in, you'd have to put it to some sort of public domain on, let's just say, Vercel, and then all of this is fully working.
So when you get in here to set this up, you're just gonna have to connect things like your Google account, a back end database, and your Stripe account. And if you guys wanna get this for free, all you have to do is go to my free school community, which looks like this. The link is in the description.
You'll go to classroom, and you'll to all YouTube resources. You'll be able to grab the whole setup guide in there and get set up in one day.
So, anyways, let me go ahead and copy this link, open up a new tab, paste that in here, and show you guys what that actually looks like, this booking flow. You can see that I've set up for this to be the description. I could obviously change that.
This is coming through as our custom branding, and I'm gonna be able to go ahead and choose a date and time. So this is live to my real calendar. I'll go over to the actual calendar.
We're looking at Friday. You can see that I can only book in from two to about three and then from four to 04:30, and this is the real calendar.
So you can see all day tomorrow is blocked off in the morning, and then three to four is blocked off. So this is coming through as accurate. And then if I go to, like, next week, there's nothing at all next week besides these two calls, 9AM to 11AM on Monday.
And if we come back into the booking link and I go to Monday, you should see that we don't have 9AM up until 11AM. So this is syncing live. If I was to, on Monday real quick, put in some big block from, like, one till six, we'll just call this busy.
We go back over here. Oops. Wrong tab.
We just give this a quick refresh. And now if I go to Monday, all those times are blocked off. So it's syncing live.
Anyways, I'm gonna go to Friday, and I'm just gonna book in for 04:15, and we're gonna move on to the next screen. This is where we can obviously put in some information.
So I'm just going to put in Nate, uh, sample email address, which actually is real. We're just gonna call this test and test, and then we can go ahead and review the booking.
This page, though, I could ask more questions when I create an event type. So I'll show you guys that in a sec. But then I'm able to just go ahead and confirm the booking, and then this is the screen that the user who is confirming or setting up the booking sees.
They get a little notification. We can reschedule or cancel it. And then if I go back to my calendar and I go to Friday, we now see that we have the strategy call with that email address that put that in right there.
And then right here, I'm in the actual email that I just signed up for that booking call with. And you can see right here, we got the invites on our calendar, and I'm just able to go ahead and accept that. So back in the actual app, what does it look like to make an event type or edit one?
Well, if you wanna edit one, you just come in here, you click edit, and then you're able to change the color of it. So you're able to change the description, the link, the name. You can change the location.
You can change how the availability works. So you can add a buffer. You can do a date range.
So very similar to Calendly, and then you can also change what questions you're asking. So you get full customization here on how many event types you need and what they need to do, all that kind of stuff. And if you're creating one, it's basically the exact same thing, name, description, booking link, time, all this kind of stuff.
You have full customization here. And then you also get to like I said, you can choose if it's going to be free or paid. And if it's paid, you set the price and people have to pay it.
So let me show you real quick what that looks like to go through a paid flow. So I'm gonna do this again on actually, let's go to Wednesday of next week. So it's, like, completely open.
I'm gonna grab a slot at 10AM. We're gonna move forward. This is going to be same person.
So this person is, like, really anxious to book in some time and get something figured out. And, also, one thing I wanted to call out.
So, like, I just realized this was one of the manual improvements that I had to make. Also, this email is wrong. Um, one of the manual improvements that I remember making was even though the agents clicked through all of this, they didn't find any bugs after they kept testing.
But what I noticed was you as a human, you come in here and you think, okay. I'm on the review stage, and I wanna get back to the time.
I wanna click up here. Right? Because there's this little progress bar.
But the UI originally was not designed to have these buttons be clickable. It was only designed so you would have to explicitly click on these arrows. And I don't know about you guys, but I would always immediately click on these rather than going to click on this little arrow that doesn't really capture my attention.
So that's one of those things where, you know, later I talk about some of the other things that I did in this project, But I came back and I did some redesigns on the user experience. Because even though the agents were really good at finding bugs, they didn't always think about the experience the same way that a human does.
Even though I prompted them to, they missed something like this. And I just wanted to call that out because that is something I explicitly remember thinking to myself, like, that's going to be a much better user experience. So, anyways, let's go ahead and pay for this.
What happens is it takes us to a Stripe booking link. So it says confirming. It's gonna take us over to a different link.
Now this is a sandbox environment, so I'm putting in, like, this fake card, but all you'd have to do is switch out the API keys for a real Stripe and then boom, it works. So let me show you how that works real quick. So what Stripe has you do is you use this number as a sandbox card, then you put in any combination here for these two things.
And this would just simulate what it would actually look like for the user to go through this flow of putting in their card, paying. And there you go. Now you can see that we just got that paid scoping session notification with Nate at Wednesday, September 2 10AM.
But, yeah, that's basically it. It's a super, super simple interface. Now I will say it's missing some of the, like, automation functionality that Calendly has, but that could really easily be worked in now that you have, you know, Codex or Cloud Code that is fully aware of this app existing and what you wanna add to it, and you can also build those automations right in there if you please.
Of course, you can come in here and do other things like change your availability. If you wanna work on Saturdays and Sundays, you can change your, you know, time of operation. You can change your time zone.
You can add date override, or you can add time off. And once again, now that this is yours, all you have to say is, you know, oh, can you just change how this works, or can you add this functionality?
Because now whenever you feel a pain point due to snag time, due to the way I built it, you just ask Codex or Cloud Code to add more functionality into this thing because . Okay. So now let's get into how I built this and what it actually looked like as far as, like, these stats.
So before I get into these stats, let me talk about what I did because I really only shot off, like, five prompts. So what I did at first was I started off with a massive slash goal prompt.
And inside of this prompt, was basically like, hey. I need you to essentially, we're gonna clone Calendly here, and and I wanna be able to run it locally and for free. What I need you to do is kind of work in four phases.
The first phase was research. The second phase was planning. The third phase was building, and then the fourth phase was actually testing.
And then this kind of ran into this loop where it would test and then build and then, you know, test again and then keep going. But that's kinda what I said, and I wanted to research Calendly and cal.com and research what people say they don't like about it and what people like about it. And, basically, take that research into the planning phase where now we have the features and functionality that we're looking for and then planning out how are we actually feasibly going to be able to do this with sub agents and with a back end database and with, you know, integrations.
What does it actually look like? And then once it was able to do all that planning, it started building. And it built and built and built, and then I had it go in this test loop where after it built, I didn't want it to give me a POC.
I wanted it to put, like, 50 agents through it to have them go through the admin experience, the sign up experience, the, you know, creating an event type experience. They they tested the thing for me so many times before I even had to get in there. So they basically went in this loop where they were building, finding bugs while they were testing, and then fixing the bugs, and then testing again, finding more bugs, and fixing the bugs, and this alone went on for days.
And I just think that whole, like, agentic autonomous testing loop is just so so cool. So, anyways, after that, what I did was I got my hands dirty a little bit, and I didn't love what came back. Because initially what came back was an app that looked really, really vibe coded.
So my next thing I wanted to do was I wanted to rebrand. It came through, and it was originally called Tempo Cove. So, like, locally, if I go into my project real quick, you can see right here that it's still a project called Tempo Cove inside of my hirk two because that's what it wanted to name it at first, which I didn't love.
So I did a rebrand. Now it's called snag time. I think that I kind of redesigned the UI a little bit better as well.
So we did a rebrand and sort of like a redesign, and this was just me giving some feedback. And then from there, what we did is we just did a bunch more testing. So one thing that happened that it didn't catch was it was, like, really, really laggy.
I don't know why, but it was so slow. So we were doing, like, performance enhancements. Um, on the actual booking link, it just like, my mouse was glitching.
Typing was slow. It just wasn't very responsive, so we optimized that. I did a slash goal prompt, I said, hey.
I need you to cut down all of this, like, load time. I need you to make this, like, ten milliseconds instead of, like, you know, one second or whatever it was.
And it did a lot of enhancement on the actual lagginess and the responsiveness of the site itself. I came back in. The fourth thing that I did was I did more more designing.
I mean, I I know it still doesn't look great, but, like, the UI oh, oops. That's not how you spell it. Not only was the UI a little bit weird, but the experience was weird.
So I kind of moved around some of the buttons a little bit. I'm obviously not a design expert, and like I said, this isn't, like, the most amazing thing ever still, but trust me, it's better than what I got. So really the point I'm trying to make here was showing you what I had to do was that, yes, the initial slash goal prompt was awesome, and, yes, I was able to get so much done with just a few prompts, but I don't wanna also discredit how hard it is to build and scale a SaaS product.
I think there's a big difference between building a product that you can use internally for a small team and building something that you want to truly scale, like tens of thousands of dollars per month. Inference, databasing, there's gonna be so many bugs.
There's gonna be so many feature requests. Even if I was to just adopt this fully internally, which I want to, I'm gonna find so many bugs, and I'm gonna find so many things that I need to take ownership over or someone on my team needs to take ownership over.
So it's not just as simple as a few prompts, and you now have something that can, you know, stand the test of time. So now that that kind of, you know, I guess, kinda boring stuff is out of the way, let's talk about this. So first of all, how long did this take me?
Well, this actually took five days and five hours of actual agents running and coding, which I thought is pretty interesting. In total, this took this was like a two week thing because, you know, I'd shoot off prompts and then I'd work on other videos, and sometimes I'd be sitting there idle for a while. But actual working was about five days.
So in that five days, though, it was an aggregate of three hundred and thirty four total hours of different agents running. Now they were running in parallel, doing things in parallel, but three hundred and thirty four hours of just straight codex .
And throughout this process, it only spun up 76 agents. Now these were unique sub agents, and I think that what happened here was it reused a lot of agents.
Like, agents would come you know, they'd come. They'd grab a task. They would then do something, and then they'd report back, and then they'd sit there and wait.
I think that's what happened. What I was kind of interested in was, you know, as far as how many times it actually delegated work to sub agents, this was way more in at least 300, I'd say, because I did so many testing loops and verification loops where I had 50 agents at least going out as a swarm to click around and try to break the app.
So that was the sub agents. Let's talk about the cost. Input tokens was 32,103,178,736 input tokens.
Output tokens, 47,000,000, which I actually thought might like, I I was expecting that to be more.
But then when you look at the actual cost in dollars, this was a $15,000 project.
Now I was on my Codex $200 a month plan, so I didn't pay $14,000. $15,000, thank goodness. But it's interesting because $14,000 is roughly what you get out of maxing out a $200 per month codex plan.
Whereas in Cloud Code, if you max out that $200 plan, it's about $8,000 in inference. So you are getting about $6,000 more inference out of codex than Cloud Code if you max out the plan, and I maxed out this plan for sure when I was running this. I even dipped into the usage credit territory, so probably a $150 of this total cost was me actually paying out of pocket, but the rest was just my $200 a month plan.
So, anyways, hopefully, you guys find those stats interesting. But like I said, this would not be completely free forever if I wanted to truly use this.
It would be me having to probably shoot off a few prompts every month, making a few enhancements every month as new bugs pop up. But for the most part, it's probably better than paying a subscription if you're willing to dedicate some headspace to actually maintaining this thing on the back end. But, anyways, if you guys are interested in kind of watching what this full process looks like when it comes to connecting some of the, you know, credentials and integrations and things, then definitely check out this video right up here where I basically did, like, a live build all day where I just built a different SaaS product.
So check it out right here. I'll see you guys over there.
The Hook
The bait, then the rug-pull.
The creator opens by stacking his free clone against the incumbents it replaces, Calendly at an estimated $3 billion valuation, cal.com at roughly $150 million, and claims he matched their core functionality in one week with a handful of prompts. The rest of the video spends its first half proving that claim with a live demo, then spends its second half quietly walking that framing back with the real invoice.
Named ideas worth stealing.
07:30list
The four-phase slash-goal build
- Research
- Plan
- Build
- Test (looped: build, find bugs, fix, retest)
A single upfront prompt instructs the agent to work through four phases in order, with build and test looping until swarms of sub-agents stop finding bugs during simulated user walkthroughs.
Steal forany multi-day autonomous build where you want to hand off a whole feature area in one prompt instead of babysitting each step
How they asked for the click.
VERBAL ASK
02:05link
“if you guys wanna get this for free, all you have to do is go to my free school community... You'll be able to grab the whole setup guide in there and get set up in one day”
soft mid-roll plug for a free Skool community that hosts the actual setup guide, positioned as the payoff for watching rather than a hard sales pitch; the paid AI-agency offer only appears in the description, not spoken on camera
MENTIONED ON CAMERA
FROM THE DESCRIPTION
PRIMARY CTAWhere the creator wants you to go next.
AFFILIATECommission earned if you click.
OTHER LINKSAlso linked in the description.
Visual structure at a glance.
