What Does It Really Cost to Build an App With an AI Coding Agent?
A real project breakdown of building a full SaaS clone with an AI coding agent: agent runtime hours, prompt count, and what plan tier actually covers.
How much does it actually cost to build an app with an AI coding agent?
The honest answer: it depends far less on “tokens” than most people assume and far more on agent runtime and plan tier. One creator cloned the core functionality of Calendly, a scheduling tool with competitors valued anywhere from $150 million to $3 billion, using a subscription coding agent plan rather than pay-per-token API billing. The build ran for about 5 days and 5 hours of actual agent execution time, spread over roughly a week of calendar time, with only a handful of high-level prompts driving the entire process. Because the work happened inside a flat-rate plan, the marginal cost of that runtime was effectively zero beyond the subscription itself.
TL;DR
- A working Calendly clone, complete with booking flows, calendar sync, and Stripe payment integration, was built using around five prompts and roughly 5 days and 5 hours of cumulative agent runtime.
- The project ran on a flat-rate subscription plan rather than metered API pricing, meaning the compute cost to the builder was fixed regardless of how long the agents worked.
- Agents ran in autonomous loops of building, testing with simulated users, and fixing bugs, which is what consumed most of the runtime rather than the initial code generation.
- Human intervention was still required for rebranding, UI polish, and performance fixes, showing that agent output needs a manual pass before it’s presentable.
- The gap between “working prototype” and “production SaaS” is the real cost driver: scaling to real users adds inference, database, and infrastructure spend that a single clone project doesn’t capture.
- Pricing an AI-built app means separating agent subscription cost, cloud hosting cost, and third-party service fees (Stripe, database, auth) since only one of those was covered by the flat plan.
What actually drove the runtime, not just the prompt count?
The headline number people fixate on is “five prompts.” That’s technically accurate but misleading if you’re trying to estimate cost. A single initial prompt set off a structured, multi-phase process: research, planning, building, and testing. The testing phase is where most of the runtime went. Instead of returning a finished product for human review, the agents were instructed to simulate dozens of users clicking through sign-up, booking, and admin flows, looking for bugs on their own. When they found issues, they fixed them and re-tested, looping through that cycle for days without a human in the loop.
This matters for cost estimation because agent runtime scales with how much autonomous verification you ask for, not with how many prompts you type. A one-line prompt that triggers a multi-day autonomous test loop will cost more in compute time than ten prompts that each just ask for a small manual tweak. If you’re budgeting for an agent-built project, the variable to watch is the scope of self-testing you authorize, not your prompt count.
Is a flat-rate agent plan cheaper than pay-per-token API pricing?
For a project like this, yes, at least on paper. Running an agent continuously for 5+ days on a metered API would rack up a token bill that scales with every file read, every test click, every retry loop. A flat monthly subscription caps that exposure: you pay one price whether the agent runs for 10 hours or 100. That’s a meaningful trade-off for anyone doing sustained, autonomous, multi-day builds rather than short one-off requests.
The catch is that flat-rate plans have usage ceilings and are optimized for a certain volume of work. A project that runs agents nonstop for the better part of a week is exactly the kind of workload that tests those limits. Someone running the same build on a metered API, prompt by prompt, would likely spend more per session but have no risk of hitting a plan cap. Someone on a subscription gets predictable cost but needs to manage how much autonomous looping they authorize inside a billing cycle.
What did the agent get wrong that a human had to fix?
The build wasn’t hands-off from start to finish. Several rounds of manual correction were needed:
The app initially generated its own name and branding (it named itself “Tempo Cove”), which needed a manual rebrand and light redesign to feel like a real product rather than a placeholder.
Performance was a problem the automated testing loop didn’t catch. The booking page was laggy, with slow typing and unresponsive UI, and that required an explicit prompt asking the agent to cut load times down from roughly a second to near-instant.
Seven tools to build an app. Or just Remy.
Editor, preview, AI agents, deploy — all in one tab. Nothing to install.
UX judgment was inconsistent. The agent’s automated testers clicked through the booking flow correctly but didn’t flag a UI pattern that a real human would find confusing: clickable-looking progress bar steps that weren’t actually clickable. That’s a class of problem functional testing doesnn’t catch, because the app “worked,” it just didn’t feel intuitive. Fixing it took a manual pass and explicit feedback, not another automated test cycle.
This pattern (functional correctness first, human polish second) is a recurring theme in agent-built software. Automated agents are good at verifying “does this button do what it’s supposed to,” but weaker at “does this feel right to a first-time user.”
Is the cost of the code the whole cost of the product?
No, and this is the part easiest to overlook. A five-day agent build gets you a working prototype you can run locally or self-host for internal use. It does not get you a hardened, multi-tenant SaaS product ready for paying customers at scale. Getting from “clone that works for me” to “product that serves thousands of users” adds costs the original build doesn’t touch: production-grade database hosting, authentication infrastructure, customer support tooling, ongoing bug fixes surfaced by real users (not simulated ones), and inference costs that scale with usage instead of staying flat under a subscription.
The distinction worth budgeting around is internal tool versus market product. If you’re building something for yourself or a small team, an agent-built clone running on a flat-rate plan can genuinely cost close to nothing beyond the subscription you’re already paying. If you’re trying to turn that same clone into a business, the agent-build phase is the cheap part. The scaling phase (databases, uptime, support, compliance) is where real spend begins, and it wasn’t part of this project’s scope.
Frequently Asked Questions
How many prompts did it take to build the Calendly clone?
The core build was driven by around five high-level prompts: an initial goal prompt covering research, planning, building, and testing, followed by a few follow-up prompts for rebranding, performance fixes, and UI adjustments.
How long did the agent actually run?
Cumulative agent runtime was about 5 days and 5 hours, though the project stretched over roughly a week of calendar time since the builder worked on other projects in between prompts.
Does a flat-rate agent plan mean the build was free?
It means the marginal compute cost was covered by an existing subscription rather than billed per token. There’s still a fixed monthly cost for the plan itself, plus separate costs for hosting, database, and services like Stripe once the app moves beyond local use.
What’s the difference between this build and a production-ready SaaS app?
This build is a functional clone suitable for personal or small-team use. Turning it into a product that serves paying customers at scale requires additional investment in infrastructure, ongoing bug fixes from real users, customer support, and inference costs that grow with usage, none of which a short agent build accounts for.
What kinds of bugs did autonomous testing miss?
Automated agent testing caught functional bugs (broken flows, slow load times) but missed UX issues, like UI elements that looked clickable but weren’t wired to respond, that only became obvious when a human actually used the product.
