Can I Move My App Somewhere Else?

If you copy an app's code and its screen loads, is the move complete? This synthetic-app simulation on one computer checked two things separately: running in another folder, and using records and files with the original-service route blocked.

One synthetic app was copied to a separate folder on the same Mac. A local program stood in for the original service, and some packages deliberately omitted components. These were two reset repetitions of one app, not a real provider's export, a move to another computer or a general success rate. The app was authored in an Astra AI-agent assignment session. The measured runs made no model calls, and AI itself was not being evaluated.

What the documentation says: there is more to move than code

Lovable's documentation describes hosting the part of an app that people see elsewhere while retaining its Cloud service for supporting functions such as data. Supabase's documentation explains that database backups exclude the actual files held in its Storage file service. That does not mean the files cannot be moved. Support for these two statements was rechecked on October 5, 2026. This experiment did not export either product.

What the experiment recorded: the same code in three packages

This article uses five categories: code, records, settings, file contents and services. Settings include service addresses; services include programs that supply records and files. A dependency is something the app still needs to work.

The test ran on September 27, 2026, with 20 records and 3 attachments. All three packages used the same code. A contained only code and settings pointing to the original service. B added a database snapshot and settings for local records, while still fetching files from the original service. C also included all three files' contents and relative settings for local records and files. It did not receive an extra service program. The results checked the deliberately constructed omissions; they did not uncover unexpected vendor defects.

Each condition began with fresh copies and fresh browser state, with cache disabled and service workers bypassed. A local forwarding route either allowed requests through or immediately returned HTTP 503 (“service unavailable”) without contacting the original service. “Blocked” below means this condition. It is different from cancellation or switching off Wi-Fi. Behavior with caching enabled, timeouts, connection refusal, partial failures or authentication errors was not tested. The second repetition reversed the order to check for state carrying between conditions. This was 3 packages × 2 states × 2 repetitions: 12 conditions for one app, not 12 independent apps.

One separate baseline check ran only a disposable copy of the original service. Before and after restarting that service, records matched 20/20 and file contents and record-to-file links each matched 3/3. Editing the note field of record R05 changed only the disposable source database. The unused destination database copy and preserved originals stayed unchanged. That edit was not carried into later conditions.

In the Records column, a record counts only if all 7 fields match, out of 20 records. List and detail views were checked separately and gave the same count in every condition. A 20/20 result includes matching values and types, with no missing, extra or duplicate IDs. It cannot identify dependencies outside those seven fields. File contents means matching contents fetched through the download routes, out of 3. Match counts were the same initially and after restarting the copied app. After a successful edit, only the designated R05 note change was expected on restart.

A's records and files under allowed access, and B's files under allowed access, came from original-service responses, not contents held in the destination package. B's records and C's records and files were supplied by their local configuration. “Destination” means the copied app's folder and database. Requests count app forwarding attempts to the original service across the initial observation, edit and restart observation. Diagnostic requests checking the route's allowed and blocked states before each condition are excluded.

C's 0/0/0 counts audited app forwarding requests. In all 6 blocked conditions, none of these requests reached the original service. This was not an audit of every browser transmission or every possible path for reading original files. Operating-system-level browser isolation had been removed, and a separate browser-blocking check has no execution evidence. Complete isolation, including for C, was not established.

In 12/12 conditions, the initial and restarted page returned HTTP 200 with the app title. That alone does not mean the functions worked. In A with access allowed, the R05 note edit was saved only to the original service's disposable database. It remained visible after restarting the copied app, but had not been saved at the destination. The write location was determined from both databases' before-edit, after-edit and post-restart states and request traces, not from the screen alone. In A with access blocked, the list, details, files and edit all returned HTTP 503. The 0/20 result means inaccessible records, not deleted records; the failed save was not loss of a previously saved record.

In B with access blocked, all 3/3 record-to-file links remained, but none of the three files' contents could be retrieved (0/3): 메모.txt (Korean for “memo”), table.csv and bytes.bin. A name or link is different from the file itself. File links also matched 3/3 in the other conditions, except A with access blocked: the records were inaccessible, so their links could not be checked. Edits in B and C went only to the destination database and persisted after restart. No condition changed either database beyond the designated note, and the preserved originals stayed unchanged.

C's result covers only these records, files, the note edit and restart. Record creation, deletion and attachment replacement were not tested. Login, payments, email, background jobs and runtime AI features were neither implemented nor tested.

B's six requests were three file requests initially and three after restart. The summary record does not itemize the paths making up A's 52 and 51 requests, so they are not asserted to be identical call sets. Before each condition, one allowed diagnostic reached the original service. A blocked condition's log therefore still contains that earlier access, separate from the table's app requests.

Preparation failures and what remains unverified

The first pre-run check was put on hold because the permitted network and browser scope conflicted with the test requirements. After clarification, three separate attempts stopped for configuration, record-integrity and browser-execution problems respectively. Each measured 0/12 conditions; none was counted as an app-function failure. The fourth attempt after clarification observed all 12 conditions. The experiment record preserves the detailed errors and baseline preparation history.

The program running the tests was corrected before measurement, while the app, data, packages, order and scoring rules stayed unchanged. However, operating-system-level browser isolation was removed, so blocking the browser's own background traffic was not proven. There is no execution record for a separate check of whether the browser blocks a local port outside its permitted list; its result and duration are unknown. This is a different check from the observed HTTP 503 blocking on the original-service route. Part of the intervening relocation of temporary test folders is also undocumented.

The environment was macOS 27.0 arm64, Python 3.9.6, SQLite 3.54.0, Chrome 153.0.8010.53, Node v24.19.0 and the installed Playwright module. The final automated run took about 42 seconds, including the baseline; that is not how long an app migration takes. Total build and correction time, beginner migration time, total cost, model identifier, CLI version and subscription usage were not measured. This does not show that moving an app costs nothing or improves productivity.

The test did not establish portability to another machine or operating system; real providers' export permissions, difficulty or costs; public deployment; production security; legal ownership or licenses; or actual cancellation. Moving browser-held values, saving files through an operating-system download dialog and opening them in a separate application were also not tested.

My judgment: record write locations and file contents

In my view, “Can I see the edit?” needs two further questions: “Where was it saved?” and “Are the file contents still available without the original-service route?” C cannot establish portability or success rates for apps in general. Intentionally retaining the original service is also an option.

This is an initial checklist. Preserve the original account and data, and begin by comparing one declared read function on a copy with the expected contents. A code copy can still write to the original service: test edits only after isolating even the connected service's data into disposable test copies. If you cannot establish that separation, do not write; record “unknown.” Beginner usability has not been tested. The checklist does not certify a successful move or show that cancelling the original account is safe.

For each row, mark the planned location as “local/original service/unknown.” Always record whether it was checked without the original-service route (yes/no/not done), and which database received an edit (location/not done/unknown). This is not an instruction to cancel or block a live service. If you cannot inspect routing and storage in a test environment, independent operation remains “unknown.” Inclusion in an export and operation without the original service are separate judgments.

Record the contents compared, whether fetched file contents match, and whether an edit to disposable data survives restart. If you checked 3 items, write “3 items checked”; do not turn that into a claim that everything matches. Mark unknowns as “unknown” and name whom to ask.

AI assisted with research and drafting. The author reviewed the final manuscript and directed the revisions.