Skip to content

Change a worker-built app safely

Stage 7 of 8: change

To change a live worker-built app safely, make every change in version history you can roll back, in small steps, with the app's whole test table run before and after, and with the review its tier requires. If you aren't the original builder, start from the app record, not from the AI chat history. Re-answer the six tier questions whenever the change adds users, data, reach, actions, a decision about people or a new owner. This applies to every live worker-built app, whether it was vibe-coded, built on a low-code platform or written by hand.

Who this is for

Builders changing their own live app, maintainers who inherited one, and app owners deciding whether a change can go out. About 8 minutes.

A change goes back through verify before it's released; this page covers what to do around those checks. The gates for changes at each tier are in the gate matrix: every release from Team up passes the tier's tests and review, in version history you can roll back; Critical apps change through IT's change process; and an app in audit scope follows the compliance owner's change requirements at any tier.

What does each kind of change need?

Every release re-runs the whole test table and the self-check. Some changes need more. The table is also a download, with a re-tier question for each row: change-checklist.csv (Prompt to Prototype, Change a worker-built app safely, https://prompt-to-prototype.com/lifecycle/change/, as of 2026-10-22. Licensed CC BY-SA 4.0).

Kind of change Example Before you change it Also check after
Content or settings New wording, a new dropdown value, a sharing setting Note the current setting in the app record Re-run the access tests if sharing, roles or sign-in changed (how to test your app)
Logic A new rule, a changed calculation Add a test case for the new rule, with the expected answer Reconcile totals against the source (reconcile totals)
Data model A new field, table or data source Check the data class of what you're adding (data handling) Data rules cover the new table or field; re-tier if the class went up
Integrations A new connector, API or system the app writes to Confirm the connector is approved and the credential is scoped Re-tier if the app now writes to a shared system or sends messages
Agent permissions A new tool, scope or OAuth grant Answer the six questions for the new permission (M3) Record the grant in the app record; repeat the trifecta check (MCP and agents)
AI model or prompt A new model version, an edited prompt Run the eval set and save the scores Re-run the eval set; compare with the saved scores (evaluate an AI feature)
Provider model retirement The provider announces a retirement date Put the date in the app record; plan the switch before it As for a model change, in good time before the date
Platform or dependency update A platform version, a library, a deprecated connector Read the release notes; export a copy Re-run the whole test table

Don't: edit production directly

A change made straight in the live app has no tested version and no clean way back. Change and test a copy, then release it. At Important and above, test and production are separate (environments).

How much review does each release need?

The gate matrix sets which reviews apply to a release. How deep each one goes:

  • Always in full, every release. The whole test table from Team up; the negative access tests from Important; and the automated part of the technical check (the exposure scan and the data-rule negative tests).
  • May focus on what changed. Only the human business review and the reading of the diff or settings, plus one regression case the reviewer picks. Take the scope from version history or git diff, not the AI's summary. If the change touches data rules, secrets, sharing, sign-in or grants, re-check that item of the fixed list in full. With no reliable diff, the review is full.
  • Full re-review triggers: a tier change, a new data class, a new AI feature or agent grant, new external users, a new owner, or 12 months since the last full review. A regenerated app is a new build and gets a full verify.

Hypothesis to test

We expect a focused review, on these conditions, to catch about as much as a full one for small changes. Test it by giving a sample of focused-review releases in your pilot a full re-review and comparing the findings.

Don't: accept a change because the AI's summary sounds right (AP10)

A fluent summary ("I only changed the label") is a claim. Check the diff or version history and run the tests (failure patterns).

How do I keep a version I can roll back to?

Before every change, make sure you can get back to what works now.

On an AI app builder or low-code platform:

  1. Check the platform's version history or "restore" feature covers both the app and its data settings. Some version the screens but not the database rules.
  2. If there's no version history, export or duplicate the app before each change, named with the date and release number.
  3. Make the change in a test copy where the platform allows one (environments), and write the release number and a one-line description in the app record.
  4. Roll back once on purpose, in the test copy, so you know it works before you need it.

With code: commit before you ask the AI for anything, keep one change per commit, and tag each release. git diff shows what the AI actually changed, which is often more than it says, and git revert undoes one release.

Version history covers the app, not always the data. If a release changes or deletes records, back up or export the data first, and check the runbook says what to do with data written since the last release.

Why add a test before you change an app?

So you can tell whether the change did what you meant and broke nothing else.

  1. Write the case for the current behavior if the table lacks one. It should pass.
  2. Write the case for the new behavior, with the expected answer. It should fail, because nothing has changed yet.
  3. Make one change. Ask the AI for that change only.
  4. Run the whole table. The new case should pass and every old case should still pass. If an old case fails, find out whether the change broke something or the old expectation was wrong.

Don't mix a tidy-up and a behavior change in one release, or you won't know which broke a test.

After you release

  • Watch for a set period, for example the first day of real use: whoever is on the app's support route checks errors and user reports.
  • Agree the rollback trigger in advance, such as a wrong total, an access failure or a test case that fails in live use, and roll back on it rather than patching live.
  • Tell users what changed in one line, and where to report problems. The runbook holds the rollback steps (document your app).

Should I edit the app or regenerate it?

Edit it. Ask the AI for targeted changes ("change the overdue rule from 30 to 45 days in the reminders step"), not a fresh build from a new prompt. A regenerated app is a new app: every screen, rule and setting may have changed, including the data rules you tested.

A vendor's analysis of 211 million changed lines found copy-pasted code rising and refactored code falling sharply between 2021 and 2024, as AI assistants spread (GitClear; correlational, not a causal claim).1 Repeated regeneration is one plausible way an app fills with duplicated code. Treat that as a risk, not a measured effect.

Don't: regenerate a whole live app from a new prompt without tests

Without a test table, you can't tell what the regenerated app does differently. If it really needs rebuilding, treat it as a new build: spec, test table, full verify, then switch over with the old version kept for rollback.

Keep the platform and its parts current

An app nobody changes still needs upkeep. Apply the security updates the platform or your technical reviewer flags, re-running the test table after each, and read retirement notices: as of October 2026, for example, Microsoft says new Dataverse for Teams environments can't be created from 15 November 2026, and environments that aren't upgraded are decommissioned on 30 October 2027.2 Send notices to a shared mailbox, not the builder's own inbox, so they're still read after the builder moves on.

What do I do when the AI model changes or is retired?

Treat it as a logic change: re-run the eval set before and after, and don't release if scores drop below the pass threshold (when the model changes or is retired).

As of October 2026, one provider promises at least 60 days' notice for publicly released models on its own platform,3 another at least 6 months for generally available models, 3 months for specialized variants and about 2 weeks for previews,4 and a third gives only "earliest possible" dates.5 Through a cloud provider's model service, that provider's dates apply. Record the model and its retirement date in the app record, with the review date ahead of it.

Don't: let a provider's model retirement date pass without re-running your evals

A retired model may be swapped for a replacement or the calls may fail, and prompts tuned to one model often behave differently on the next.34 Switch on your timetable, with your eval set.

When does a change mean re-tiering?

Re-answer the six tier questions and both flags before you release a change that (when to re-tier):

  • shares the app with a new team, or with anyone outside the business;
  • adds data of a higher class, such as personal details beyond business contact details;
  • makes any part reachable without company sign-in;
  • writes to a shared system, sends messages, deletes records or changes them in bulk;
  • adds an AI feature, or gives an agent a new tool or grant, or changes an agent's grants;
  • means its output starts being posted to the ledger or used as control evidence without anyone recomputing it (Q4(d1));
  • starts ranking, scoring or flagging people, or lets a decision about a person take effect before it's reviewed (Q5);
  • changes the app owner.

Some of these need no technical change: "finance started posting from it" or "add a flag for late performers" can make an app Critical. A higher tier brings its gates with it before release. A Team app that now holds Confidential data needs every Important gate before that release goes out, including the business review, technical check, data-owner sign-off, negative access tests and separate production (verify gates; deploy gates).

How do you change an app you didn't build?

Start from the app record, not the builder's AI chat history, which records what was asked rather than what was built, and may be private or gone.

  1. Read the app record and runbook; if either is missing, write it first (document your app).
  2. Run the test table on the current release, so you know your starting point.
  3. Check you can roll back, then make one small change and verify it.

A new owner triggers a re-tier and a full re-review. If the builder has left, when the builder leaves covers reassigning the owner and revoking their access first.

If you're a professional developer

  • Small commits, one intent each, with the AI's diff reviewed before you commit.
  • Pin dependencies in a lockfile, and check every new package the AI adds exists and is reputable (dependencies).
  • Keep tests in the repository and run them on every change; with a pipeline (circumstance C6), block merges on a failing test.
  • For refactoring, pin behavior with tests first, and keep refactoring and behavior changes in separate pull requests.

Assumptions and evidence

  • A-012 (Medium): we expect review to become the bottleneck as AI-assisted change volume rises, so small changes matter more; test this by tracking release size and review wait.
  • A-013 (Medium): we expect the benefits of AI-assisted change to depend on foundations already in place (tests, version history, small steps, review); test this by comparing rollback rates for apps with and without a maintained test table. Evidence: vendor repository analysis (correlational), provider deprecation policies, a vendor retirement notice, and the durable practice of testing before changing. No study measures how worker-built apps fare after changes. Facts on this page are as of October 2026.

  1. GitClear, "AI Copilot Code Quality" research (211 million changed lines, 2020 to 2024; correlational), 2025. https://www.gitclear.com/ai_assistant_code_quality_2025_research [vendor], accessed 2026-10-22. ↩

  2. Microsoft Learn, "About the Microsoft Dataverse for Teams environment" (page updated Oct 2026). https://learn.microsoft.com/en-us/power-platform/admin/about-teams-environment [vendor], accessed 2026-10-22. ↩

  3. Anthropic, "Model deprecations" (the notice applies to Anthropic-operated platforms; cloud providers set their own schedules). https://platform.claude.com/docs/en/about-claude/model-deprecations [vendor], accessed 2026-10-22. ↩↩

  4. OpenAI, "Deprecations". https://developers.openai.com/api/docs/deprecations [vendor], accessed 2026-10-22. ↩↩

  5. Google, "Gemini API deprecations". https://ai.google.dev/gemini-api/docs/deprecations [vendor], accessed 2026-10-22. ↩