When the original builder leaves, an internal app often keeps running. The immediate danger is quieter: the organisation may no longer know how to change it, remove access safely, rotate its connections, explain its business rules or recover the last working version.
Do not begin with a rewrite. First establish control over six things: the workflow rules, administrative ownership, data, secrets and connections, releases and recovery, and the knowledge required to operate the app. Then decide whether to keep, rebuild or retire it.
Having the source code, a shared login or a live URL does not settle that question.
The app can run while ownership has already failed
An internal tool is more than its screens. It contains decisions about who may act, which record comes next, what blocks progress, how an external account is used and what happens when a step fails.
If only one employee or contractor understands those decisions, their departure creates several risks at once:
- The app runs under a personal account the organisation does not control.
- A former user retains access or a reusable credential.
- Nobody can explain a rule that blocks or approves work.
- A connection fails and no one knows which account owns it.
- A change goes live with no known previous version.
- The organisation owns a code archive but cannot build, release or operate it.
This is key-person dependency expressed through software. It may not appear on the builder’s last day. It appears at the first permission change, failed integration, policy update or urgent request.
GitHub’s ownership-continuity guidance recommends at least two organisation owners because projects can become inaccessible when the only owner is unreachable. The exact controls differ across platforms, but the rule is sound: important business software needs more than one accountable organisational owner.
Take control of six custody layers
Use this table to determine whether the organisation controls the app or merely has permission to use it today.
| Custody layer | Evidence of organisational control | Warning sign |
|---|---|---|
| Business rules | A current workflow brief names the states, roles, exceptions, required evidence and finish condition. | The rule is “ask the builder” or lives in an unexplained formula. |
| Administrative ownership | At least two named owners use organisation-controlled accounts and can manage membership and roles. | The sole owner uses a personal email, phone or payment method. |
| Data | The organisation knows where live data resides, who may export it, the retention terms and how recovery is tested. | A spreadsheet export exists, but nobody knows whether it is current or restorable. |
| Secrets and connections | Every external account, token and domain has an organisational owner, purpose, scope and rotation path. | A connection depends on the former builder’s private account or copied API key. |
| Release and recovery | The current version, approval record, previous working version and recovery boundary are visible and tested. | “Rollback” means hoping the builder has an older copy. |
| Operating knowledge | A second person can run the workflow, diagnose a common failure and complete a controlled change. | Documentation lists features but not how the operation is actually handled. |
Do not mark a layer complete because a document exists. Ask the backup owner to use it. A handover is proven when a new responsible person can carry out the task without private instructions from the original builder.
If the builder has already left, contain the risk in 48 hours
The exact timing depends on employment law, contracts and the circumstances of the departure. Coordinate with your HR, legal and security owners where appropriate. The sequence below addresses application continuity, not the full employee-exit process.
Freeze non-essential changes
Stop feature work and unplanned configuration edits. Preserve the current live state, recent logs and release information. A well-meaning fix during an uncertain handover can destroy the evidence you need to understand the system.
Assign two accountable owners
Name a primary business owner and a backup. Give them organisation-controlled accounts. One should understand the workflow; the other should be able to manage access and recovery. They may be the same two people in a small team, but neither responsibility should exist only in a former worker’s account.
Remove access and review every route back in
Disable or remove the person’s app membership. Review administrator roles, source repositories, cloud accounts, deployment tools, domains, payment accounts, email providers and connected services.
The NCSC identity and access guidance recommends a joiner, mover and leaver process so access can be changed or revoked when no longer needed. NIST SP 800-171 Rev. 3 likewise calls for disabling system access and revoking authenticators and credentials when employment ends.
Removing an account is necessary, but it does not retrieve every copy already made. GitHub notes in its organisation member removal guidance that a removed member may retain local copies even though they can no longer sync them. Your contract, confidentiality process and data-handling obligations still matter.
Rotate credentials the person could access
Do not change every key blindly. Inventory the credentials first, identify dependencies and rotate the ones the departing person could read or use. Test each affected connection after rotation.
The OWASP Secrets Management Cheat Sheet describes a secret lifecycle that includes creation, rotation, revocation and expiration. It also recommends recording who and what consumes each secret, its purpose and who to contact about it. That inventory prevents a security response from becoming an avoidable outage.
Capture the current operating state
Record the live version, release date, data location, integration list, recurring jobs and known failures. Create the export or backup currently available under the product and plan. Do not assume the file is useful until someone has opened it and confirmed what it contains.
Run the critical workflow
Choose one normal record and one awkward exception. Follow each from start to finish. Capture any step that requires the former builder’s memory or account. Those gaps become the handover backlog.
Transfer the workflow, not only the code
Code explains what the app does mechanically. It may not explain why the business selected that rule, which exception is acceptable or which record requires a manager’s judgment.
A useful workflow handover answers:
- What event starts the work?
- What result closes it?
- Which roles touch the record, and in what order?
- Which information is required before each hand-off?
- Which decisions are automated, suggested or always human?
- What can be retried safely?
- Which outside actions cannot be reversed by an app rollback?
- Who owns policy changes after the handover?
Bring real, redacted examples. A clean sample often hides the exception that drove the app’s value in the first place.
KasiLabs starts from this business account of the work. A customer describes the people, task, evidence, safeguards and expected result in plain language. That plan remains useful after the first build because it gives future reviewers a human-readable basis for the app. The guide on what to tell us before we build can also be used as a rescue interview when the original brief never existed.
Move ownership out of personal accounts
List every account involved in building and operating the app:
- App-builder workspace.
- Source repository.
- Domain and DNS.
- Email sender and verified domain.
- Database and file storage.
- Payment or billing account.
- Analytics and monitoring.
- Automation, AI and document services.
- App-store or distribution account, if applicable.
For each one, record the organisation owner, backup owner, billing contact, recovery method and access-review date. Avoid shared passwords. Assign individual accounts with the smallest role each person needs.
KasiLabs workspaces place membership, roles, projects, releases and spending choices under workspace-owner control. Building, reviewing and publishing can be separated. When a member leaves, an owner removes that access and server-side checks protect the underlying actions, rather than relying on hidden menu items.
This does not eliminate the need for offboarding. The organisation still decides when access should end and who assumes the responsibilities.
Inventory connections without copying the secrets
A handover document should not become a password vault.
Record metadata for each connection instead:
- Service and organisation account.
- Business purpose.
- Permissions granted.
- App workflows that depend on it.
- Credential location.
- Rotation and revocation owner.
- Failure and retry behaviour.
- Current cost or usage boundary.
KasiLabs uses managed app connections so sensitive account keys do not have to live in browser code or the generated app’s own source. The app receives only the approved capability, and paid actions are subject to the workspace’s limits. That narrows the handover surface. Someone must still own the outside account, understand what the connection does and decide whether it remains necessary.
Start with the smallest connection set. An app that cannot explain why it has a credential should not keep it.
Prove the release and recovery path
Find the current live release and its approval record. Then identify the previous working version.
Run a small continuity drill in a private or working environment:
- Make a harmless visible change.
- Ask the backup owner to review it.
- Approve it through the ordinary release path.
- Confirm the live version and release record.
- Restore or roll back to the previous version.
- Verify the critical workflow again.
The NIST contingency-planning guide ties recovery strategy to business impact and calls for recovery plans to be tested and maintained. A written rollback instruction that nobody has run is not yet evidence.
KasiLabs keeps revisions, release checks, approvals and deployment history together. Authorised owners can restore an earlier revision or request a previous deployment, and material actions are recorded. The working-copy and live-release guide explains this separation.
Application rollback has limits. It does not unsend an email, undo an accepted payment or automatically reconcile an outside database. Record those external effects and their recovery owner before calling the drill complete.
Test the export and rights you actually need
“We own our data” and “we can operate elsewhere next week” are different statements.
Ask the current platform:
- Which data can be exported, in what format and by which role?
- Does the export include files, history, role definitions and business rules?
- Can an authorised owner export the current application revision?
- Which parts depend on the platform runtime or reusable components?
- What happens at termination, and how long is an export available?
- Have you tested the destination, or only downloaded an archive?
KasiLabs provides an authorised, audited revision-export path in the current product. Its terms state that customers keep their submitted content and may use application-specific code and output subject to the agreement, third-party licences and full payment, while KasiLabs retains its platform and reusable materials.
Do not turn that into a one-click migration promise. If self-hosting or a specific destination is mandatory, test the complete path before committing the workflow.
Run the continuity test before accepting the handover
The handover passes only when the backup owner can do all of the following without the original builder:
- Explain the normal workflow and one important exception.
- Add a test user with the correct role, then remove them.
- Find the current release and the person who approved it.
- Identify all external connections without exposing their credentials.
- Locate the latest data and application-revision export.
- Make and review a private change.
- Restore the previous working version.
- Explain which external actions need separate reconciliation.
Record failures. Do not hide them inside a generic “documentation needs improvement” task. Each failure points to a specific custody layer that remains with the former builder.
Decide whether to retain, rebuild or retire
Once immediate control is restored, make the longer-term decision.
| Decision | Choose it when | Do not choose it merely because |
|---|---|---|
| Retain | The workflow is important, ownership is organisational, access is controlled, current behaviour is understood and recovery works. | The app still opens today. |
| Rebuild | The workflow remains valuable, but the current platform, permissions, code or connections cannot be made maintainable at reasonable risk. | A new builder promises a prettier interface. |
| Retire | The workflow is no longer needed, a standard product now fits, or the control cost exceeds the remaining value. | Nobody wants to own the handover. |
If you rebuild, do not clone every screen. Recover the workflow decisions first. Preserve the records and evidence that matter, then create the smallest app that can carry the job with more than one owner.
Rebuild orphaned workflows with organisational control
KasiLabs helps an operations team turn the knowledge behind an orphaned app into software the organisation can review and control. Describe the existing workflow and the exceptions the old tool handled. Build a private working version. Assign at least two accountable owners, separate review from release where appropriate, approve the exact version that goes live and test rollback and export before the handover is declared complete.
KasiLabs cannot remove key-person risk by itself. No platform can make a company document what it refuses to document or assign a backup owner it never names. What it provides is a workspace where the plan, access, releases, history, spending boundaries and recovery path do not have to remain inside one builder’s head.
Describe the orphaned workflow in KasiLabs and use the continuity test above as the acceptance criterion for the replacement.
Sources
- GitHub: Maintaining ownership continuity for your organisation, accessed 12 August 2026.
- GitHub: Removing a member from your organisation, accessed 12 August 2026.
- NCSC: Identity and access management, accessed 12 August 2026.
- NIST SP 800-171 Rev. 3, accessed 12 August 2026.
- OWASP Secrets Management Cheat Sheet, accessed 12 August 2026.
- NIST SP 800-34 Rev. 1, accessed 12 August 2026.
- NIST Secure Software Development Framework, accessed 12 August 2026.