Why an AI-built app works in preview but breaks after deploy
The five differences between a Lovable, Bolt, Replit or Cursor preview and real hosting, in the order worth checking, with a fifteen-minute test.
Service
Find out what your AI-built app actually needs
A convincing demo and a working product are different things. If your vibe-coded app works in preview but fails after deployment, or another prompt breaks a working feature, start by identifying the failure. Wilde Digital inspects the application and proposes the smallest workable repair. You can buy the inspection without committing to a rebuild.
Start an inquiryAll rates and terms
- $1,500 USD per agreed inspectionInspection and a prioritized findings report.
- From $3,500 USD per agreed repair scopeSeparately agreed repair scope after inspection.
- Evidence firstSource inspection, runtime checks and proposed repairs are labeled separately.
When should you stop prompting and inspect?
An inspection fits a founder who can show the source and describe a failed user journey, but cannot yet tell whether the application needs repair or replacement. It is particularly useful when different tools have changed the same project. Access and platform fit are checked before the inspection scope is accepted.
- You can provide the current repository or an export that includes the application source.
- You can describe the expected result and the failure a user actually sees.
- You can identify the hosting, database and third-party services the app depends on.
- You want a decision between repair, a smaller product and replacement—not reassurance that everything is almost finished.
What does the inspection deliver?
The inspection produces a source and configuration map, a feature-status inventory, evidence-backed findings and a proposed order of work. Each finding distinguishes what was observed from what still needs a runtime check. You receive the report without having to buy implementation, and proposed repairs are not reported as completed fixes.
- Application entry-point and dependency map, including secondary prototypes where they affect ownership.
- Configuration inventory using variable names and responsibilities, not copying secret values into the report.
- Feature inventory separating observed working behavior, failures, partial implementations and unverified claims.
- Findings with evidence, user impact, dependencies and uncertainty stated alongside priority.
- A recommendation to repair, reduce scope or replace, with the reasoning and missing information visible.
- For an approved repair: the agreed source changes, exercised acceptance conditions and handover notes.
What do inspection and repair cost?
| Work | Published rate | What the rate covers | What moves the price |
|---|---|---|---|
| AI project rescue inspection | $1,500 USD per agreed inspection Inspection window agreed after access and application scope are confirmed. | Inspection of the agreed application, source and configuration map, feature-status inventory, evidence-backed findings and a prioritized repair recommendation. Runtime checks are distinguished from source inspection. | Repository boundaries, available runtime and access. Implementation, account recovery and security certification are excluded. |
| AI project rescue implementation | From $3,500 USD per agreed repair scope Quoted after the inspection identifies the changes and verification requirements. | A bounded group of repairs selected after inspection, verified against agreed user journeys, with source changes and handover notes. | Dependencies, affected user journeys, test environments and external integrations. New product features and unlimited rescue work are excluded. |
The written quote confirms the scope, schedule, payment milestones, revisions, cancellation and handover terms. Ongoing work is optional and separately scoped.
What has Wilde Digital actually inspected?
The documented example is a read-only inspection of an anonymized conversation-assist application using React, Vite, Capacitor and Express. It produced eight findings, including development-only API routing and misleading failure feedback. No build, server, migration or deployment was run for that example, and its proposed repairs are not presented as successful delivery.
Describe the failure before sharing access
Tell me what the app should do, what happens instead, which AI coding tool or builder was used, its stack and whether the source is available. Name the user journey that matters most and any deadline. Do not put passwords, production keys or customer data in the inquiry; appropriate access follows an agreed inspection scope.
Scope boundaries and exclusions
This is not emergency incident response, a penetration-test certification or a promise to support every stack. A new agency build from approved designs belongs under white-label web development. A Shopify catalog or theme problem belongs under Shopify development, where store-specific constraints can be scoped directly.
- An unlimited whole-codebase security audit or compliance certification.
- Recovery of unavailable account credentials or deleted historical data.
- Production changes, database migrations or destructive actions without specific approval.
- Unrelated new features or an unapproved change of framework.
- Third-party fees, continuous monitoring, emergency support and guaranteed recovery.
The quote identifies any separately available work and third-party costs.
Delivery and handover
- Describe one concrete failure. Give the starting state, action, expected result and observed result. Identify the version involved. A recording or screenshot can establish the symptom, but source and an appropriate runtime are needed to establish its cause.
- Agree safe access. Confirm the repository, permitted AI-assisted tooling, test data and allowed commands. Avoid sending production secrets or customer records through an inquiry form. Missing access is a scope constraint, not a reason to improvise with sensitive data.
- Map what runs. Read the scripts and trace the delivered application, including server boundaries and deployment configuration. Mark dead or unused code separately so an abandoned feature is not counted as working product behavior.
- Classify findings. Separate defects, missing functionality, configuration problems and uncertainty. Group symptoms with a common cause. A report should help you choose the next action, not inflate a count by describing the same exposure three different ways.
- Agree the repair boundary. Pick a bounded group of changes and define proof of completion. Decide any account, architecture or business-policy questions before implementation. If replacement is the better recommendation, it is a separate scope rather than an automatic rewrite.
- Repair and demonstrate. Exercise the agreed failure path after the change. Record the environment and limitations, including whether a packaged device or live provider was actually tested. Source changes alone do not justify declaring a mobile feature or deployment fixed.
Handover includes the agreed source or access, documentation and verification notes. The quote sets any optional support terms.
A useful rescue leaves fewer unknowns, not a larger backlog disguised as completion. The final record should identify the exact journeys that now pass and the dependencies that remain. Search problems in an otherwise working site may instead need technical SEO; they are not a reason to rebuild its application.
Eight findings from a real read-only inspection
The inspected application accepted a conversation and returned a suggested reply. Its React and Vite client used Capacitor for mobile packaging and an Express service for an external language-model API. A separate Next.js-shaped prototype was not used by the root build; treating both as one product would overstate the shipped client.
One finding concerned native API connectivity: the client could fall back to a relative endpoint supported by a development proxy, while the packaged-build workflow did not supply a native API base. That is a source-supported configuration finding. It is not a claim that an APK was built and tested, because no build or server command ran during this inspection.
Another finding grouped reflected CORS, absent visible rate limiting and missing server-side payload bounds under one trust-boundary problem. The priority recommendation put that boundary before making the external API easier to reach. Fixing connectivity first could make an unprotected paid endpoint more accessible. The exact access policy remained an owner decision.
The inspection also found failure feedback converted into ordinary advice while success haptics still fired, speech functionality present only in an unused prototype, and iOS packaging claims without the corresponding platform directory. These distinctions mattered more than a broad claim that the app was “ninety percent done.” They identified what existed, what was missing and what a runtime check would still need to prove.
The eight findings were prioritized with user impact and dependencies separated from uncertainty and verification difficulty. The worked example then described a repair plan. No client recovery, successful release or commercial outcome is claimed from that record. The value demonstrated is the inspection method and the restraint to avoid calling an unexecuted plan a result.
Questions people actually ask
- Can I submit an app built with Lovable, Bolt, Replit or Cursor?
Send the tool name, the current source repository or export, and the user journey that fails. Acceptance depends on the actual framework, dependencies, access and agreed scope—not the builder name alone. A preview link is useful context, but it does not replace source access or establish that every part of the app can be repaired.
- Can you guarantee that my app can be rescued?
No. The inspection is designed to answer whether repair is sensible before you authorize it. The answer may be a narrower product, a repair, a replacement or a dependency that must be resolved first. Paying for inspection does not commit you to buying implementation.
- Do I need to know how to code?
No. You need to describe what a user should be able to do and provide appropriate access to the project. The report explains findings through their impact and next action, alongside technical evidence. Decisions about budget, accounts, data and product scope still remain yours.
- Will you rewrite the application?
Not by default. Working parts should be kept when they support the agreed product. A replacement needs a specific reason, such as an unsupported dependency or a structure that makes the required change impractical. It is quoted and approved separately rather than introduced as an unannounced cleanup.
- What if the application cannot run locally?
Source inspection can still establish some facts, but runtime claims remain unverified. The report names missing configuration, accounts, devices or services. You decide whether obtaining those prerequisites belongs in a follow-up scope. A read-only finding is never described as a reproduced production failure unless that failure was actually observed.
- Is this the old AI Project Rescue download?
No. The historical self-serve kit and its existing download links remain separate. This page describes a done-for-you inspection and optionally agreed implementation. Purchasing or holding the old material does not imply that a repair engagement, audit credit or ongoing support is included.