Planning and Cost
What Does It Cost to Productionize a Vibe-Coded App?
A transparent framework for estimating productionization work based on uncertainty, risk, integrations, data, and the condition of the existing codebase.
There is no responsible universal price for productionizing a vibe-coded application. Two products with the same number of screens can require radically different work: one may be a stateless content tool, while the other moves money, separates customer data, and depends on asynchronous integrations. The visible interface is a weak proxy for production risk.
A useful estimate explains assumptions, uncertainty, and tradeoffs. It distinguishes work required for a safe launch from work that improves maintainability later, and it accounts for discovery when the generated code does not reveal a coherent architecture. This prevents both inflated wish lists and artificially low estimates that omit operational work.
The framework below helps founders prepare a budget conversation, compare proposals, and choose a smaller first release when necessary. It deliberately avoids fabricated market averages and focuses on the properties that actually change effort.
/01
Why screen count does not determine the estimate
A screen can display static text or coordinate identity, billing, permissions, background jobs, and third-party APIs. The second screen carries more states, failure paths, and verification work. Generated applications can also duplicate logic across screens, making a seemingly small change expensive to apply safely.
Estimate the system behind the interface. Count user roles, sensitive data classes, business rules, integrations, and workflows that change durable state. Then identify operational expectations such as uptime, support response, audit history, and recovery. These dimensions expose the real scope more reliably than pages or components.
- More roles create more authorization combinations to implement and test.
- Payments, regulated data, and irreversible actions increase assurance needs.
- Background processing adds retries, status tracking, and recovery paths.
- Unclear product rules create design work before implementation can be estimated.
/02
The six major scope and cost drivers
Condition of the existing code affects how much can be retained. Clear boundaries, consistent types, and a reproducible build reduce uncertainty. Hidden coupling, duplicated generated code, insecure client-side logic, and undocumented provider configuration increase investigation and remediation.
Product consequence affects the depth of validation. A team should spend more effort proving isolation and recovery for a multi-tenant financial workflow than for a disposable event microsite. This is not unnecessary engineering; it is matching evidence to potential harm.
- Codebase health: structure, types, dependencies, tests, and build reproducibility.
- Data: schema quality, migration needs, volume, sensitivity, and retention.
- Identity: login methods, organizations, roles, invitations, and account recovery.
- Integrations: API quality, webhooks, rate limits, sandbox access, and failure behavior.
- Operations: monitoring, backups, deployment, incident response, and support tools.
- Product scope: unresolved rules, edge cases, accessibility, and launch expectations.
/03
Use discovery to reduce uncertainty before committing
When the codebase and requirements are uncertain, begin with a bounded assessment. The output should include a system map, high-risk findings, a retain-versus-replace recommendation by area, a prioritized launch scope, and an estimate range with assumptions. Discovery is useful only if it produces decisions, not merely a long defect list.
Ask the assessor to demonstrate representative findings. Examples include tracing a sensitive request from browser to database, running the application from a clean checkout, or restoring a sample backup. Evidence helps distinguish a structural problem from a stylistic preference and makes competing proposals easier to compare.
- Provide repository, deployment, database, and provider access through secure channels.
- List the must-work journeys and known failures before the review begins.
- Agree on what the assessment will not cover.
- Require assumptions and confidence levels alongside estimates.
/04
Separate launch scope from improvement scope
Create three buckets: launch blockers, near-term hardening, and optional improvements. Launch blockers are defects with unacceptable consequences, such as cross-account data access or no recovery for critical records. Near-term hardening may include broader tests or operator tooling. Optional improvements might include internal refactors that do not yet reduce material risk.
This sequence protects the budget without hiding technical debt. Record deferred work with its consequence and trigger, such as reaching a user threshold or adding a second engineer. Avoid vague labels like clean up the code. Every item should connect to user value, risk reduction, delivery speed, or operating cost.
- Remove low-value features before weakening controls around retained features.
- Use a limited beta when fewer users materially reduce exposure.
- Defer scale work until measurements show where the bottleneck exists.
- Do not defer basic authorization, recoverability, or secret management.
/05
How to compare proposals and commercial models
A fixed scope can work when the product rules and code condition are understood. A time-and-materials model can fit exploratory remediation but needs a clear priority order, spending checkpoints, and visible progress. A staged model often works well: assessment, launch-critical implementation, validation, and optional follow-on work.
Compare what each proposal includes, excludes, and proves. Check responsibility for design decisions, data migration, infrastructure, provider fees, testing, launch support, and post-launch defects. A lower total that excludes these tasks may not be a lower cost to reach the same outcome.
- Look for milestones expressed as working outcomes rather than hours alone.
- Ask how newly discovered risk changes scope and who makes that decision.
- Confirm ownership of source code, environments, domains, and provider accounts.
- Require a handoff package even if an ongoing support relationship is planned.
/06
Build a realistic budget and contingency
Budget for the implementation and for the systems required to operate it: hosting, databases, email, monitoring, identity, storage, and any usage-based APIs. Model those operating costs against plausible usage scenarios rather than one optimistic number. Include internal time for decisions, acceptance testing, content, legal review, and provider approvals.
Keep a contingency tied to known uncertainty, not an arbitrary promise that nothing will change. The appropriate amount depends on evidence from discovery, integration quality, and requirement stability. Anodize productionization projects start at $7,500, and ongoing retainers start at $5k/month. Those minimums are context for fit, not a quote; an actual scope depends on the codebase, risk, and desired launch outcome.
- Fund discovery separately when uncertainty is too high for a credible build estimate.
- Review spend at meaningful scope checkpoints.
- Track third-party costs independently from engineering fees.
- Reserve post-launch capacity for observed issues and user feedback.
Frequently asked
Questions about this topic.
Can I get an estimate without sharing the codebase?
You can get a rough planning range from workflows and architecture, but confidence will be limited. Repository and environment review is usually necessary to determine whether existing code is reusable and to uncover security, data, and deployment work hidden by the interface.
Is rewriting usually more expensive than improving the prototype?
Not always. Improvement is often efficient when foundations are coherent. A selective or full rebuild may be less costly when core assumptions are wrong, logic is deeply duplicated, or remediation must preserve structures that actively resist safe change.
How can I reduce cost without creating launch risk?
Reduce the number of workflows, roles, integrations, or supported edge cases in the first release. Preserve controls around identity, sensitive data, recovery, and critical actions. A smaller safe product is usually a better trade than a broad fragile one.