How much does it cost to finish a vibe-coded MVP?

The cost of finishing a vibe-coded MVP depends on what already works and what the intended release still requires. Review the core journey, access rules, data, integrations, deployment, and handover before estimating. A flat price based only on screenshots leaves the most expensive uncertainties unresolved.

Publishing can involve requirements beyond a development preview. Replit's publishing documentation, for example, distinguishes the published application and its operating setup. Whatever platform you use, include that setup in the scope you ask suppliers to price.

Which work remains after the prototype?

Separate four categories: defects in existing behaviour, missing release features, changes to the architecture or platform, and operating preparation. Those categories have different assumptions and should not disappear into one line called "make it production-ready."

For an illustrative customer portal, the interface may be largely complete while invitations, permissions, file access, and notifications still require work. Counting completed screens would overstate how close that app is to a usable release.

Ask the reviewer to demonstrate the important workflow and identify where it stops. That gives the estimate a concrete starting point.

How can I compare proposals?

Have each supplier price the same intended outcome. If a quotation excludes data migration or support, record that explicitly before comparing totals.

What does a useful estimate calculation look like?

As an illustration, suppose a review identifies 30 hours of feature work, 12 hours of integration changes, and 18 hours of verification and release work. That is 60 estimated hours. At an assumed rate of ₹2,000 per hour, the calculation gives ₹120,000 before any separately agreed charges.

Those figures are invented to show the method, not a FoundrySoft quote or a market benchmark. The important point is that changing the integration assumption changes the estimate. A supplier should explain uncertainty and how additional work will be authorized.

Include your own team's time for decisions, test data, and acceptance review. The development invoice is not the entire cost of delivering the project.

What should we avoid paying for prematurely?

Do not buy a large feature expansion before establishing whether the existing workflow can be supported. Equally, do not remove necessary review and recovery work merely to reach a smaller headline price.

Agree a narrow first scope when uncertainty is high. A review with concrete findings may provide a better next decision than committing immediately to a fixed-price completion project based on incomplete information.

Separate running costs from build costs. An app can be inexpensive to launch but costly to operate if every task triggers several paid services or needs extensive human correction. Model representative monthly usage and identify who monitors it.

Turn the prototype into a priced scope

Share the current app and the smallest release your users need. Discuss a scoped MVP completion project to identify the remaining work, acceptance criteria, and assumptions behind an estimate.

Frequently asked questions

Can you quote from a demo video?

A video can explain the goal and visible behaviour, but a reliable completion scope may require repository, configuration, and integration review. Ask what assumptions a video-only estimate relies on.

Is AI-assisted development always cheaper?

No universal saving follows from using an agent. Implementation may be faster in some areas while review, integration, data preparation, and maintenance still require time.

Should maintenance be included in the build quote?

It should be addressed clearly, whether included or priced separately. Record coverage, responsibilities, operating costs, and how new features differ from defect fixes.