Preview and production are not always the same environment
You build an application in Lovable, test it in the editor, and everything appears to work. Then you publish it, share the link, and discover that customers cannot log in, certain pages show errors, or important features stop responding. The immediate temptation is to ask AI to fix the code. But what if the code itself is not the problem?
Consider a hypothetical customer-booking application. Creating a booking works perfectly in preview, but the published version displays an error after submission. One possible explanation is that the live application is connecting to a different backend or using incorrect configuration. Another is that the browser is rejecting a request. Without examining the deployed version, repeatedly rewriting the booking feature might make the situation worse.
Find the difference before changing working code
A developer would first examine the browser console, which displays errors from the running website, and the network requests, which show calls made to backend services. They would compare these findings with deployment logs, configuration settings, and the release version actually running. Common areas to investigate include missing environment variables, incorrect callback URLs, cross-origin resource sharing (CORS) restrictions, cached files, and routing configuration that fails when someone opens a page directly.
Some settings are embedded when an application is built, while others are supplied when it runs. This distinction between build-time and runtime configuration matters when diagnosing published apps. Lovable's publishing documentation also confirms that publishing deploys a snapshot; later editor changes do not automatically update the live version. A stale published release could therefore explain behavior that appears inconsistent with preview. None of these possibilities should be treated as the cause until evidence supports it. Never solve connection errors by exposing private API keys or disabling security controls.
When should you ask a developer to investigate?
If the same feature works in preview but fails after publishing, repeatedly asking AI to rewrite it may waste time. You need someone who can trace the application across its build, hosting, backend, and browser.
DitchNow helps founders and small businesses troubleshoot AI-built applications and prepare them for real customers.
Book a technical discussion with DitchNow.
Five prompts to investigate publication failures
Before you begin: Use these prompts one at a time in the same project conversation. Give the assistant access only to approved project materials, use synthetic test data, and review its findings before approving changes.
1. Map
Inspect my application's deployment architecture and configuration. Map the differences between preview, development, and published environments. Identify build processes, hosting, environment variables, API endpoints, callback URLs, routing rules, caching, and release versions. Reference actual project files and available deployment information. Clearly identify what you cannot inspect without additional authorized access. Do not change code.
2. Audit
Perform a read-only deployment diagnosis for this symptom: [DESCRIBE FAILURE]. Analyze approved, sanitized deployment logs, browser console errors, and failed network requests where available. Check for build-time versus runtime configuration differences, CORS restrictions, wrong callback URLs, routing fallback problems, cached assets, and outdated releases. Rank possible causes by supporting evidence rather than guessing.
3. Plan
Create a targeted remediation plan based on the confirmed findings. Identify whether each problem requires a configuration correction, deployment change, or actual code modification. Specify affected files and settings, safe configuration handling, regression tests, and acceptance criteria. Preserve functioning behavior and existing security controls. Do not implement anything.
4. Challenge
Review your plan critically and identify overlooked environment differences. Design a staging test that reproduces the published build as closely as possible. Include direct-page navigation, authentication redirects, API requests, browser cache behavior, and failure handling. Explain which checks can be automated, which require human verification, and what remains unknown.
5. Implement
I approve the following changes: [APPROVED SCOPE]. Apply them only in an isolated staging environment. Build the application, run appropriate tests, inspect sanitized logs and network behavior, and compare results against the failing scenario. Report modified files, configuration changes, tests passed, and remaining risks. Do not expose credentials or deploy to production automatically.