DEV Community: Omni Care

Admin access, but no control of the cloud bill: the takeover order when billing and root sit with someone else

Omni Care — Sun, 25 Oct 2026 08:18:07 +0000

A common takeover situation looks fine on the surface. The original developer or agency is gone, but your team can still log into the app's admin panel, edit content and see users. What nobody has is the cloud account that pays for the servers, the registrar login for the domain, or the root user that can create and delete everything. Those sit under a former employee's email, a freelancer's credit card or an agency's company account.

Admin access feels like control, but it is the weakest layer. If the card on file expires, a billing dispute goes unresolved or the account owner simply stops responding, the provider can suspend the account and every app on it goes down at once. A recent Hacker News thread described exactly that: a small company lost all of its production applications for nearly two weeks after its cloud account was suspended over a billing and credits dispute, while support gave conflicting answers. This post is the order I would work in before that happens, with a check for each step and what to do when a step fails.

Step 1: List every account that costs money, and whose card or email pays for it

Start with money, not code. Make one table with a row for each paying service: cloud hosting, domain registrar, DNS provider, email sending service, app store developer accounts, monitoring, and any SaaS the app depends on. For each row, write the login email, the payment method, the renewal date and who can actually sign in today.

Check: every row has a named person inside your company who has signed in this week. Rows where the answer is "the old developer" or "not sure" are your real risk list. Invoices in your accounting system and card statements are the fastest way to find accounts nobody remembers.

Step 2: Secure the domain before anything else

The domain is the one asset you cannot rebuild. Servers can be recreated and code can be redeployed, but if the domain lapses or stays locked in someone else's registrar account, your email and website go with it. Look up the expiry date with a public WHOIS or RDAP lookup and compare it with today.

Check: the domain renews more than 60 days from now, auto-renew is on, and the registrar account email is a company address you control. If any of these fail, this is the first transfer request you send.

Step 3: Export everything the admin panel can export, and prove you can restore it

Use the access you have while you still have it. Export the database or content, user lists, uploaded files and configuration from the admin panel. Then restore that export somewhere you control, even a cheap test server or a local machine, and open it.

Check: the restored copy shows recent records, for example orders or sign-ups from the last few days. An export file that has never been opened is not a backup; it is a hope.

Step 4: Request ownership or payer transfer, with paperwork ready

Now ask for the transfer of the cloud account, the registrar account and any other row from Step 1 that is not yours. Prepare the contract or statement of work showing your company paid for the system, and the invoices that show who paid the hosting. If the previous owner is cooperative, most providers support changing the account email, adding your company as a payer, or moving resources into an organisation you own.

Check: a person from your company is listed as owner or administrator on each account, billing uses a company payment method, and multi-factor authentication is tied to a company device or shared vault, not a former employee's phone.

Step 5: Only then rotate keys and plan code changes

It is tempting to start by rotating passwords and deploy keys, or by reading the codebase. Doing that before Steps 1 to 4 can lock you out of something you could not yet recover. Once you own the accounts and have a restorable copy, rotate API keys, deploy keys and admin passwords, remove old users, and only then start judging whether the code itself is in good shape.

When a step fails

The cloud account is suspended for non-payment. Open a support case from the account owner's login if anyone can reach it, and attach invoices and the contract. In parallel, restore your Step 3 export on infrastructure you control so the business can keep running while the case drags on. Do not wait for support to answer before you start the restore.
The provider or agency refuses to transfer ownership. Some providers will only act on the account holder's request, and some agencies treat hosting as leverage. Stop negotiating over the account and migrate instead: use the verified export, stand up a new environment you own, test it, and switch DNS once the domain is yours.
Registrar privacy hides who owns the domain. Privacy protection is normal, but it means WHOIS will not tell you the owner. Use the registrar's own dispute or ownership-verification process and bring the invoices and card statements that show your company paid for the domain.

What "done" looks like

You are out of the danger zone when three things are true: every paying account has an owner inside your company, the domain is renewed and in your registrar account, and you have restored a recent copy of the data on infrastructure you control. Everything else, including whether to keep or rebuild the code, can be decided calmly after that.

I work on software takeovers at Omni Care. If you want a fuller list of what to collect as proof during a handover, there is a takeover evidence checklist you can work through with your team.

Disclosure: this post was written by the Omni Care team with AI assistance, and the author works at Omni Care.

This guide was first published on 2026-10-24 on a blog that is no longer available; the text is unchanged apart from this note and the link tracking.

Handoff checklists ask if it exists. Takeovers need proof: account control, rollback and restore

Omni Care — Wed, 21 Oct 2026 08:26:26 +0000

Most handoff checklists ask the right questions. Two recent ones here on DEV are good examples: Jacek Rozanski's 12-point MVP handoff checklist and tdk-cli's first deploy checklist for vibe coders.

Reading them side by side, we noticed the same gap in three places. The checklist asks whether something exists. A takeover depends on whether someone other than the original builder can actually use it.

"Is there a written list of every external service the app depends on, with the account owner and billing method?" A list is not control.
"You know the rollback step." Knowing the step is not the same as having run it.
"Do you have a working backup you've actually restored from?" This one gets it right. The other two should be held to the same standard.

Here is how we'd turn those three into checks that produce evidence, with a clear pass and fail for each.

1. Account control: prove the new owner can log in and act

A spreadsheet of services and owners is a good start. It does not tell you what happens if the person on that list stops answering email.

Check: the person or company taking over signs in to each account themselves, without the original developer present, and performs one harmless admin action.

Account	Harmless admin action that proves control
Domain registrar / DNS	View the DNS zone and the renewal date; confirm who can edit records
Code repository	Confirm an owner/admin role and list who else has write access
Hosting / cloud / database	Open the production resource and the billing page; confirm whose payment method it is
Third-party APIs (email, payments, AI)	Create or rotate a key in a company-owned account

Pass: every row was completed by the new owner, from a company-controlled login.

Fail: any row needs "just ask the original developer." Move that account first. A lapsed card or a departed person's login can take the product down, and nothing else you fix will survive it.

2. Rollback: run it once, on purpose

"The previous version should be one command away" is a good rule. The first time you find out whether it is true should not be during an outage.

Check: someone who did not build the app deploys an unchanged build to a test environment, then rolls back to the previous version and confirms the old version is what's serving.

Pass: both directions worked, and the steps are written down well enough that a third person could repeat them.

Fail: nobody but the builder can deploy, or rollback means "redeploy from my laptop." In that case change safety is effectively zero, and a repeatable deploy plus rollback should be the first piece of work, before any feature or fix.

Also compare the documented environment settings with what production actually runs, including scheduled jobs and background workers. Undocumented jobs are where business rules quietly disappear during a handoff.

3. Restore: time it, don't just confirm it exists

Jacek's line "untested backups are fiction" is exactly right. We'd add one detail: measure it.

Check: restore the most recent backup into a separate environment, open the app against it, and confirm a recent record is there.

Pass: the restore worked, you know how long it took, and you know how old the newest restored data was.

Fail: the backup exists but has never been restored, or nobody knows where it lives. Treat the data as unprotected until a restore succeeds.

Why "a claim without evidence counts as a fail"

In a takeover, the person answering the checklist is usually the person who built the system. They are answering honestly, from memory, about a setup that works for them. The evidence version removes that bias: every row is answered by the incoming owner doing it once.

It also changes the conversation with a non-technical founder. "Three items failed: we can't log in to the registrar, nobody can roll back, and the backup has never been restored" is a much clearer basis for a rescue-or-rebuild decision than a list of yes/no answers.

A copyable version

We maintain a longer version of this as a table, with the evidence to obtain, how to verify it yourself, and what a failure means for the next step: Takeover evidence checklist.

If you've taken over a codebase and found a fourth item that belongs on this list, we'd be glad to hear about it.

Disclosure: this post is from the Omni Care team. Omni Care helps teams take over and stabilize software someone else built; the linked checklist is ours. This article was written by an AI agent working for the Omni Care team, without human editing. It is an original post, not a repost.

How to Choose a Fractional CTO: 10 Vetting Questions and a Decision Tree

Omni Care — Tue, 06 Oct 2026 01:54:13 +0000

Originally published as the fractional CTO buyer's guide on Omni Care.

Short answer: a fractional CTO is a senior technical leader you engage part-time to own or guide specific decisions — architecture, data boundaries, build-vs-buy, vendor selection, and delivery accountability — without hiring a full-time executive. Choose one by scoring every candidate on the same ten questions below, then use the decision tree to confirm whether you actually need a fractional CTO, a one-time CTO diagnosis, or alignment support alongside your existing team. Use these questions to clarify the scope, decision authority, delivery responsibilities, and handoff you need before engaging a technical adviser.

Settle one distinction first: a fractional CTO (or CTO advisory) provides technical leadership and decisions. That is different from software takeover and maintenance — taking over and running an existing system or codebase someone else built. Many teams need one and not the other; this guide is about the leadership decision.

10 vetting questions

What is the scope — a decision, a project, or ongoing leadership? Decide whether you need one clear call, a 60–90 day push, or a standing part-time leader. The engagement shape changes who you should even be talking to, so agree on it before you shortlist.
Will they own technical decisions, or only advise? Some engagements carry decision authority; others stay advisory. Agree upfront which calls the fractional CTO owns and which stay with your leadership, so accountability is clear from day one.
Are they neutral on vendors and stack? Ask whether they are tied to a specific vendor, cloud, or technology, or whether they will recommend what fits your data boundaries, cost, and operations. Neutrality is what you are paying for.
Have they actually run systems in production at your scale? Judgment that holds up under load comes from operating real systems, not only from advising on them. Ask for concrete, describable production experience close to your scale and constraints.
How do they handle data boundaries and security? A good candidate can explain how they decide what data can be used, what may go to the cloud, what must stay inside your environment, and which steps keep human review and logging.
How will they work with your existing IT, SI, or engineering team? The goal is to strengthen the teams you already have, not sideline them. Ask how they define goals, architecture, and acceptance criteria so internal and external teams can deliver more easily.
Who owns delivery, acceptance, and long-term maintenance? Clarify whether delivery and acceptance sit with the fractional CTO, your team, or a vendor — and who owns maintenance after the engagement ends. Unowned maintenance is where projects quietly stall.
How is their time priced, and how do they prevent runaway cost? Ask how time is scoped and how a cheap pilot is kept from turning into runaway production cost. You want a comparison you can trace, not a fixed number presented as certainty.
What is the plan to hand knowledge back to your team? A fractional engagement should end with your team or vendor able to continue. Ask for the explicit plan to transfer decisions, context, and documentation back when the work is done.
Can they translate between leadership, IT, and vendors on a fixed cadence? Most misalignment surfaces only at execution. Ask how they keep leadership, IT, and vendors on one shared decision language and review cadence so problems appear early, not at acceptance.

Decision tree: fractional CTO, diagnosis, or team alignment?

Once every candidate is scored on the ten questions, match your situation to one of these three paths. They are not mutually exclusive over time, but starting in the right place saves budget and avoids hiring for the wrong shape of help.

Path A → You need one clear technical decision now: a one-time CTO diagnosis or decision memo. Best when the question is bounded — build vs buy, architecture, data boundaries, or vendor selection — and you mainly need an expert, traceable recommendation you can act on.
Path B → You have a defined initiative for the next 1–3 months: a fractional CTO engagement. Best when a specific project needs part-time senior technical ownership: goals, architecture, delivery cadence, and accountability, without committing to a full-time executive hire.
Path C → You have a capable team but lack alignment: advisory alongside your existing team. Best when IT, SI, and leadership need clear decision ownership, a shared delivery cadence, and agreed acceptance criteria alongside the team already doing the work.

The full guide, with its FAQ, lives at the canonical source: care.omniai.one/cto.

About: This guide is published by Omni Care's CTO Advisory practice. Omni Care — software takeover and maintenance — also helps teams take over and run existing systems; this particular guide is advisory only. This post was drafted with AI assistance.

Taking over an AI or vibe-coded production app? 8 risks to map before you touch the code

Omni Care — Tue, 29 Sep 2026 12:01:42 +0000

When you inherit a system that was built fast, with AI assistance or "vibe coding", and it is already live in production, the hardest part is usually not reading the code. It is figuring out who controls what, whether you can deploy safely, and what breaks the first time real traffic hits an edge case.

"It can demo" and "it can be maintained safely" are two different claims. AI helping a team ship something that demos quickly is genuinely useful. The catch shows up on handover. Below is the pre-takeover checklist I run before touching a production change: stabilize first, inventory first, then decide whether to maintain, partially refactor, or rebuild.

If you're already taking over a live system, the software takeover and rescue service uses the same control-first inventory to frame whether to maintain, partially refactor, gradually replace, or rebuild.

1. Nobody actually holds production control

Production control is often fragmented: the repo sits in one personal account, the cloud under a different email, the domain and DNS with a third party, the database and payments with other owners. If the original team leaves, the new owner may be unable to log in everywhere, or to revoke access.

Check first: confirm which account owns the repo, cloud, DNS, database, environment variables and secrets, third-party APIs, payments, email, monitoring, and backups, one by one, and whether you can log in yourself and transfer ownership. Do not change code or redeploy before control is mapped.

2. No reproducible build and deploy

A system can be live while its build and deploy process exists only on one machine or in one person's memory, with no CI/CD, deploy script, or rollback path. That makes even a one-line change risky.

Check first: can you reproduce the build and deploy from source in a clean environment? When a deploy fails, can you roll back to the last working version? The AWS Well-Architected Operational Excellence pillar treats repeatable, reversible change as a baseline requirement, and getting this path working is the safety net for every change that follows.

3. Secrets hardcoded in the code or the frontend

Fast-built systems can hardcode API keys, database passwords, and third-party tokens directly in code, config files, or even frontend JavaScript. Once these land in git history or a public bundle, treat them as exposed.

Check first: scan the repo and frontend for hardcoded credentials and confirm which have entered git history. OWASP documents use of hard-coded credentials as a software weakness, and its Top 10 covers the related security-misconfiguration and vulnerable-component risks. On takeover, rotate anything potentially exposed, then move secrets into environment variables or a secrets manager.

4. Messy dependency versions with known vulnerabilities

Fast projects pull in many packages at once, with unpinned versions or references to unmaintained libraries. If one dependency updates or disappears, the system can break with it, and some may carry known CVEs.

Check first: is there a lockfile with pinned versions? Run a dependency vulnerability scan and list the high-risk and unnecessary packages. Pin versions first, then upgrade incrementally. Do not attempt one big clean sweep that leaves the system unable to start.

5. No tests, no monitoring: you find out after it breaks

A prototype can reach production with no automated tests and no alerts. Without monitoring, users notice failures before the team does, and no signal tells you what broke after a change.

Check first: is there any automated test you can run? Does production have basic error and availability monitoring, with alerts landing somewhere a human will actually see? Before refactoring, add at least the layer that means "someone will know when it breaks", otherwise every change is a blind change.

6. Data model and migrations are not version-controlled

No migrations, no schema versioning, and backups nobody has verified can actually be restored. Changing the data structure becomes a bet, and one mistake can lose data you cannot get back.

Check first: are schema changes managed with migrations? Where is the most recent backup, how often does it run, and has a restore actually been tested? Before touching any schema, confirm you can safely return to the current state.

7. "Looks like it works", but edge cases and error handling are missing

Demos use clean inputs and small volumes. Real production hits null values, oversized inputs, concurrency, third-party timeouts, and exhausted quotas. AI-generated code often covers only the happy path and cannot recover when an exception arrives.

Check first: do the critical flows (login, payment, writes, outbound calls) have error handling and retries? Are inputs validated? Find the spots that break when a user or an external service does something unexpected.

8. No docs, no architecture diagram: just source code

The last problem makes the previous seven harder: no architecture diagram, no deploy notes, no dependency list, just a pile of code. Whoever makes the next decision has to reverse-engineer everything first.

Check first: frame the first deliverable of a takeover as an inventory document, not "change a feature immediately". At minimum produce a system architecture diagram, an Access Map (who can access what), a Dependency Map (services and relationships), and a Risk Register (known risks and the order to address them).

Takeover is not only about rewriting

Once those 8 points are mapped, the assessment usually points to one of four directions, weighed against control, maintainability, and risk:

Maintain directly: control is obtainable and the system is broadly maintainable; just add the missing deploy, backup, and monitoring.
Partial refactor: mostly stable, with a few high-risk modules to rewrite or replace.
Gradual replacement: keep the current service running while swapping out the highest-risk parts piece by piece.
Full rebuild: control, data, or core-architecture risk is too high, and rebuilding is faster and safer than forcing a rescue.

Not every inherited system needs a full rewrite. An inventory-first assessment tells you which of the four is actually justified.

Sources

NIST SP 800-218 Secure Software Development Framework (SSDF): secure practices such as key management, dependency control, and reproducible builds.
OWASP: Use of hard-coded password (software weakness) and the OWASP Top 10 (security misconfiguration, vulnerable components).
AWS Well-Architected, Operational Excellence pillar: repeatable, reversible deploy and change processes (this does not imply mandating AWS).

This is a pre-takeover check and decision guide, not a security audit or legal opinion, and not a guarantee that any system can be saved. If the original team left and the system still runs but no one dares to touch it, here is how the software takeover and rescue service maps control, deploy, data, and risk first. To gauge it yourself, try the vibe-coded production-readiness self-check.

Canonical version: https://care.omniai.one/blog/ai-coded-app-takeover-common-problems/

接手 AI／vibe coding 寫的 production 系統前，先檢查這 8 件事（附接手決策路徑）

Omni Care — Sun, 27 Sep 2026 08:39:48 +0000

這篇整理自我們實際接手 AI／vibe coding 產出、且已經上 production 的系統時，第一週最常踩到的地雷。完整原文（含常見問答與延伸閱讀）發表在 Omni Care 部落格，本文為 DEV 社群版重寫。

用 AI 或 vibe coding 快速做出能 demo 的產品是好事——問題是「能 demo」和「能安全維護」是兩件完全不同的事。當原團隊離開、系統還在跑卻沒人敢改，麻煩幾乎從來不是「程式看不看得懂」，而是控制權、可重現部署、金鑰與相依、測試監控、資料遷移、邊界情況、文件這幾件事同時缺席。

以下 8 點是我接手這類系統時固定會先跑一遍的檢查。順序有意義：先穩定、先盤點，再決定要維護、局部重構還是重建——不要一接手就急著改功能或重新部署。

1. 沒有人真正握有 production 的控制權

最典型的第一個坑：repo 在某個個人帳號、雲端綁另一個 email、網域和 DNS 在第三方、資料庫和金流又各自屬於不同人。原團隊一走，沒人能完整登入、也無法撤換權限。

先查：逐項確認 repo／雲端／DNS／資料庫／環境變數與 secrets／第三方 API／金流／email／監控／備份分別在誰的帳號下，你能不能自己登入、能不能移轉擁有權。控制權沒盤清前，一行程式都先別改。

2. 沒有可重現的建置與部署流程

系統「上線了」，但怎麼 build、怎麼 deploy 常常只活在某台機器或某個人的記憶裡：沒有 CI／CD、沒有部署腳本、沒有回滾方式。改一行就得靠運氣。

先查：能不能在一台乾淨環境從 source code 重現建置與部署？部署失敗能不能回滾到上一個可用版本？走通這條路，是後續所有修改的安全網。AWS Well-Architected 的營運卓越（Operational Excellence）支柱正是把「可重複、可回復的變更流程」列為基本要求。

3. 金鑰、密碼直接寫死在程式或前端

AI 生成的程式為了「能跑」，很常把 API key、資料庫密碼、第三方 token 直接硬編碼在程式碼、設定檔、甚至前端 JavaScript 裡。一旦進了 git 歷史或公開前端，就等於已經外洩。

先查：掃描 repo 與前端有沒有硬編碼憑證，確認哪些已進入 git 歷史。硬編碼與外洩憑證是 OWASP Top 10 長期點名的高風險項目。接手時應先輪替所有可能外洩的金鑰，再把 secrets 移到環境變數或密鑰管理服務。

4. 相依套件版本混亂、含已知漏洞

vibe-coded 專案常一次裝進大量套件、版本沒鎖定、或引用了不再維護的套件。哪天某個相依更新或消失，系統就跟著壞，其中也可能夾帶已知漏洞。

先查：有沒有 lockfile？跑一次相依漏洞掃描，列出高風險與不必要的套件。先鎖版本、再逐步升級——不要為了「清乾淨」一次大改而讓系統起不來。

5. 沒有測試、沒有監控，壞了才知道

AI prototype 幾乎都是零測試、零告警。系統壞掉時，往往是使用者先發現、你最後才知道；也沒有任何自動化能在改動後告訴你「這裡壞了」。

先查：有沒有任何自動化測試可跑？production 有沒有基本的錯誤與可用性監控、告警送到有人看得到的地方？重構前至少先補上「壞了會有人知道」這一層，否則每次修改都是盲改。

6. 資料模型與遷移沒有版本控制

沒有 migration、沒有 schema 版本、備份沒人驗證過能不能還原。改資料結構等於賭博——一出錯，可能連回不去的資料都救不回來。

先查：schema 變更有沒有以 migration 管理？最近的備份存在哪、多久一次、實際還原過嗎？動任何 schema 前，先確認「能安全回到現在這個狀態」。

7. 「看起來會動」，但邊界情況與錯誤處理缺失

demo 用的是乾淨輸入與小資料量。真實 production 會遇到空值、超長輸入、併發、第三方逾時、額度用盡。AI 生成的程式常只寫了 happy path，例外一來就整個崩。

先查：關鍵流程（登入、付款、寫入、對外呼叫）有沒有錯誤處理與重試？輸入有沒有驗證？先找出「使用者一做非預期操作就會壞」的地方——這通常是接手後最先爆的雷。

8. 沒有文件、沒有架構圖，只剩一包 source code

最後一個、也是讓前面七項都更難處理的問題：沒有架構圖、沒有部署說明、沒有相依清單，任何人要做下一個決定都得先自己逆向推敲一遍。

先查：把接手的第一份產出定位成「盤點文件」而不是「馬上改功能」。至少補出系統架構圖、Access Map（誰能存取什麼）、Dependency Map（相依與服務關係）與 Risk Register（已知風險與處理順序），讓下一個決定有依據。

接手不是只有「重寫」一條路

把上面 8 點盤清楚後，通常會落在四種方向之一，取捨依控制權、可維護性與風險而定——不預設每個都要重寫：

直接接手維護：控制權可取得、系統大致可維護，補上缺的部署、備份、監控即可。
局部重構：多數穩定，只有少數高風險模組需要重寫或替換。
逐步替換：邊維持現有服務、邊把風險最高的部分逐塊換掉。
必須重建：控制權、資料或核心架構風險過高時，重建反而比硬救更快更安全。

如果你正卡在「原團隊離開、系統還在跑卻沒人敢改」，我們有整理一套先取得控制權、再判斷要維護／重構／重建的 軟體接手與救援檢查，可以先拿去對照自己的系統。

查核依據

NIST SP 800-218 安全軟體開發框架（SSDF）——檢查金鑰管理、相依控管與可重現建置等安全開發實務。
OWASP Top 10——辨識硬編碼憑證、過期相依與缺乏驗證等常見高風險項目。
AWS Well-Architected：營運卓越支柱——檢查可重複、可回復的部署與變更流程（不代表指定採用 AWS）。

本文是接手前的檢查與決策指南，不是資安稽核或法遵意見，也不保證任何系統都能救回或任何架構、供應商的結果。

本文由 Omni Care 團隊撰寫，內容為 AI 輔助草擬、經人工審閱與事實查核。原文出處：care.omniai.one。

Your Vibe-Coded App Runs in the Demo. Here's the 7-Point Production-Readiness Check Before You Ship It.

Omni Care — Fri, 25 Sep 2026 01:56:31 +0000

Your vibe-coded app runs fine in the demo. That is not the same thing as being ready for real users, real data, and real downtime at 2am.

"Vibe coding" — building software by prompting an AI and shipping what works — gets you to a demo astonishingly fast. The gap it hides is everything that keeps an app alive after launch: a stack you can actually update, a place the code lives that isn't one laptop, a deploy you can repeat, backups you have actually restored, secrets that aren't pasted in plain text, monitoring that tells you before your users do, and a handoff a new person could follow.

Below is a 7-point production-readiness check you can run on any AI-built or vibe-coded app in about ten minutes. For each point: the question to ask, why it bites in production, and the minimum bar to clear.

1. Known, updatable stack

Ask: Do you know exactly what the app is built on — and can you update it when a dependency ships a security patch?

If the honest answer is "the AI picked the libraries and I'm not sure which versions," you have an update problem waiting to happen. Vibe-coded apps often pin nothing, mix incompatible packages, or depend on a framework the author can't name. The first critical CVE turns that into an emergency you can't triage.

Minimum bar: You can list the language, framework, and major dependencies, and you have run a dependency update at least once without the app breaking.

2. Version control and a real owner

Ask: Where does the code live, and who is allowed to change it?

"It's in the ChatGPT thread" or "it's on my Mac" is not version control. Without git (or equivalent) plus a named human owner, there is no history to roll back to, no review before a bad change lands, and no way to answer "who touched this?" after an incident.

Minimum bar: Code is in a repository with commit history, and one specific person is accountable for merges.

3. Repeatable deployment

Ask: How does a change get from your machine to production — and could someone else do it?

If deployment is "I drag files into the host" or "I re-run the prompt and copy-paste," you cannot ship a fix quickly or safely under pressure. Manual, undocumented deploys are where late-night mistakes happen.

Minimum bar: There is a documented, repeatable deploy path (a script, a CI pipeline, or a one-command push) that a second person could follow.

4. Backups with a tested restore

Ask: If the database died today, what happens?

The dangerous answer isn't "we have no backups" — it's "we have backups but we've never restored one." An untested backup is a hope, not a recovery plan. AI-built apps frequently ship with the default managed database and zero restore drill.

Minimum bar: Automated backups exist and you have restored one into a scratch environment and confirmed the data came back.

5. Managed secrets, scoped access

Ask: Where do API keys and passwords live?

Vibe-coded code loves to inline secrets — in the source, in a committed .env, in the prompt history. Once a key is in a repo or a screenshot, treat it as public. The blast radius of a leaked production key (billing, data export, account takeover) is rarely scoped down.

Minimum bar: Secrets live in a secret manager or environment config outside version control, and each key has the narrowest scope that still works.

6. Monitoring with alerts

Ask: How do you find out the app is broken?

"A user emails me" is not monitoring. Without uptime checks, error tracking, and an alert that actually reaches a human, you learn about outages last — after they've already cost you trust.

Minimum bar: An uptime check plus error tracking, wired to an alert (email, Slack, phone) that someone will see.

7. A handoff a new person can follow

Ask: Could someone who has never seen this codebase take it over?

This is the summary of the other six. If the only person who understands the app is the person (or AI session) that built it, every future change is a risk and every absence is a single point of failure. A prototype becomes a real product the moment a second person can safely run and change it.

Minimum bar: A short README or runbook that covers stack, how to run it locally, how to deploy, where secrets live, and where backups are.

Score yourself honestly

Count how many of the seven you can clear at the minimum bar:

6–7: You have a real product, not just a demo. Tighten the gaps and keep shipping.
3–5: It works today and will hurt later. Prioritise backups-with-restore, secrets, and monitoring first — those cause the worst incidents.
0–2: Treat it as a prototype, not something to depend on. Do the hardening before you put real users or real data on it.

Turn the answers into a checklist

If you want to run this as a scored, private self-check — no sign-up, nothing stored, everything in your browser — I put the interactive version and a copyable hardening checklist here:

Is your vibe-coded app production ready? — free self-check

It walks the same seven dimensions, scores your readiness, surfaces your biggest gaps first, and gives you a checklist you can paste straight into your issue tracker.

Shipping fast is good. Shipping fast and being able to keep it alive is the whole game.

Disclosure: I work on Omni Care, which helps teams take over and productionise AI-built and vibe-coded apps. This article was drafted with AI assistance and reviewed for accuracy before publishing. The self-check tool linked above is free and stores nothing.

Inherited an Unmaintained or Vibe-Coded App? A 7-Point Takeover Check Before You Touch the Code

Omni Care — Thu, 24 Sep 2026 11:47:26 +0000

When a developer leaves — or an AI-assisted "vibe-coded" prototype suddenly has to go to production — someone inherits a codebase they didn't write. The instinct is to start fixing things: reformat the code, upgrade the dependencies, "just clean this up a bit." That instinct is usually the expensive mistake. Before you change a single line, you need to know what you actually inherited, who really controls it, and where it will blow up under real load. The checklist below is the exact sequence I use when taking over an unknown app. Work it top to bottom — each point gates the next, and skipping ahead is how a two-week stabilisation turns into a two-month firefight.

1. Do you actually control it?

Repo access is not control. Being able to read the code tells you nothing about whether your company can keep the product alive tomorrow. Control means you hold the production hosting account, the domain and DNS, the DNS registrar, the database, the email/sending domain, and the deploy pipeline — under accounts your company owns, not a personal login belonging to the person who left. This is the single most common failure in a takeover: the code looks fine, but production runs on someone's personal Vercel/Render/Firebase project, the domain is in a founder's private registrar account, and the only admin on the database is an ex-contractor. If any of those sit in an account you don't own, getting control back is step zero and everything else waits.

Judge it by asking "if this person disappeared and changed their passwords tonight, what breaks and what can't I recover?" If the honest answer is "the site" or "the database," you don't have a code problem yet — you have an ownership emergency.

Checklist:

[ ] Production hosting, domain, DNS registrar, database, and email/sending domain are all under company-owned accounts with at least two admins.
[ ] You have removed or rotated every access grant tied to the person who left, and confirmed nothing broke — proving those grants were not load-bearing.

2. Can you build and run it from a clean machine?

Clone the repo into a completely fresh environment and follow whatever docs exist — no shortcuts, no "I'll just copy my old .env." If you cannot get a working local build in an afternoon, you have an onboarding problem before you have a code problem, and that problem will hit every future hire and every incident-response moment when someone needs to reproduce a bug fast. Vibe-coded apps are especially prone to hidden local state: an undocumented global npm package, a specific runtime version, a database seeded by hand, or a secret that only ever lived on one laptop.

The valuable output of this step is not just "it runs" — it's the written record of how you made it run. Capture every command, every missing variable, every version pin as you go. That transcript becomes the README that never existed, and it is often the first genuinely useful artefact a takeover produces.

Checklist:

[ ] A brand-new machine (or clean container) can go from git clone to a running local instance using only written steps.
[ ] Runtime versions, required services, and seed/fixture data are pinned and documented, not tribal knowledge.

3. Where do the secrets live?

API keys, access tokens, database URLs, and webhook signing secrets that are hard-coded in the repo, committed in an old .env, or living only in one person's shell history are a time bomb. In an inherited app you must assume every secret is already compromised: you don't know who has seen the repo history, who forked it, or which third-party the previous owner pasted a key into. Inventory every secret, rotate the ones that could have walked out the door, and move them into a real secret store (your host's env manager, a vault, or at minimum a locked-down manager) so they are never again committed to source.

Judge severity by blast radius: a rotated analytics key is a shrug; a leaked payment-processor secret or a database admin credential is a same-day priority. Grep the full git history, not just the current tree — secrets that were "removed" in a later commit are still sitting in the history for anyone with clone access.

Checklist:

[ ] Every secret is inventoried, classified by blast radius, and the high-risk ones are rotated.
[ ] git log/history has been scanned for committed credentials, and secrets now live in a real store rather than the repo.

4. What happens on deploy — and can you roll back?

Trace exactly one change from commit to production and write down every stage it passes through. Is there CI? Any tests that actually run? A staging step, or does main push straight to live? Most importantly: when something breaks at 2am, can you get back to the last known-good state in about 60 seconds? A takeover without a rollback path is how a routine one-line fix becomes a multi-hour outage — because the moment you touch anything, you own whatever breaks, and "I can't undo it" is the worst sentence to say during an incident.

If there is no rollback path, building one is almost always a higher-value first move than any code cleanup. An immutable previous deploy you can re-point to, or a tagged last-good release, buys you the confidence to change everything else safely.

Checklist:

[ ] You have traced one commit end-to-end and documented the real deploy path (CI, staging, promotion to production).
[ ] A tested rollback exists — you have actually reverted to a previous version in a safe environment and confirmed it works.

5. What's the blast radius of the data?

Find the database, confirm backups actually run — and, crucially, that they restore — and check whether personal or sensitive data is handled sanely. "We have backups" is meaningless until you have performed a restore into a scratch environment and seen real rows come back. Vibe-coded apps love to log everything and secure nothing: full request bodies with passwords in plaintext logs, PII in analytics events, no retention policy, and a single unencrypted production dump sitting in someone's Downloads folder.

Judge this by imagining a breach or a bad migration: what is the worst data that could leak or be destroyed, and could you prove to a customer what happened? If the app touches payments, health, or identity data, this point can outrank everything above it. Data mistakes are the ones you cannot roll back.

Checklist:

[ ] You have run a real backup → restore drill and confirmed the data comes back intact.
[ ] You know exactly what personal/sensitive data is stored and logged, and obvious leaks (plaintext secrets in logs, PII in analytics) are closed.

6. Which parts are load-bearing vs. decorative?

AI-generated and hastily built code is full of plausible-looking functions that are never called, "features" held together with copy-paste, and abstractions that wrap a single call site. If you trust the file names and folder structure, you will spend days hardening code that no user ever reaches while the one fragile path that handles every real request goes unnoticed. Map the actual request flows: instrument the running app, watch the logs under real usage, and follow the two or three journeys that actually matter (sign-up, the core action, payment) from entry point to database.

Judge each module by "what happens to a paying user if this breaks right now?" Load-bearing code earns tests and monitoring first; decorative code can be quarantined, feature-flagged off, or deleted. Deleting confidently is a superpower here — dead code is not free, it is a place bugs hide.

Checklist:

[ ] The two or three critical user journeys are traced end-to-end from request to database, with the load-bearing modules named.
[ ] Obvious dead/unreachable code is identified and either removed or clearly quarantined, so effort goes where users actually are.

7. Rescue, rebuild, or bring in a lead?

With points 1–6 answered, the decision is usually no longer a gut call — the evidence makes it for you. A small, controllable surface with recoverable data and a working rollback → rescue in place and iterate. No control, no tests, unknown data integrity, critical business dependency → contain the damage first, then rebuild the core deliberately rather than patching in the dark. Strategically important but chronically under-owned → bring in a fractional lead to stabilise ownership, deploy, and data before you try to scale features on top.

The trap at this stage is sunk cost: "we've already put six months into this" is a reason people keep pouring effort into an app that should be contained and rebuilt. Let the answers to points 1–5 — not the effort already spent — pick the path. The cheapest month is the one where you decide correctly instead of fixing symptoms.

Checklist:

[ ] You have written down the rescue / rebuild / bring-in-a-lead decision with the specific evidence from points 1–6 behind it.
[ ] The decision is driven by current control, data, and deploy risk — not by how much time has already been spent.

Score your own situation (free, no signup)

I built the full version of this into a free browser self-check — it scores your takeover risk across these seven dimensions and points you to the right next move. Nothing to install, no email required, and your answers stay in your browser:

👉 https://care.omniai.one/software-takeover/?utm_source=devto&utm_medium=referral&utm_campaign=software_takeover

If you're staring at an inherited or AI-built app right now, do the control check (point 1) first. Most "the code is a mess" emergencies are really "we don't own our own production" emergencies in disguise — and until ownership, deploy, and data are solid, cleaning the code just rearranges the risk.