When Your Overseas Team Leaves and Nobody Owns the Code

Your overseas development team stopped answering emails. Or the contractor who “built the MVP in Cursor” ghosted after the last invoice. Or the agency wound down the retainer and handed you a ZIP file with no README. The app still opens on someone’s phone. Stripe might still be charging. Users still expect features. But when you ask a simple question — where is the source code, and who owns it? — nobody has a clean answer.

I am Muhammad Adil. I am a solo AI solutions engineer and senior full-stack / React Native developer. I do not run an agency roster. Founders contact me when an inherited app, an AI-built prototype, or an orphaned codebase sits in an awkward middle ground: too valuable to abandon, too unclear to trust. This article is the practical playbook I wish every founder had before they panic-rebuild or panic-hire.

If you only need the service page after you finish reading, start here: AI app evaluation. If you already know you need a repo-level quality pass instead of a product go/no-go, see code review. If the honest answer is “rebuild mobile properly,” see app development.

The pain is not “bad code.” The pain is no place for the code

People say “the code is messy.” Sometimes it is. Often that is not the real emergency.

The real emergency looks like this:

• Nobody can log into the Git provider. The invite went to a personal Gmail that left with the contractor.
• The App Store Connect account is under a freelancer’s Apple ID, not the company.
• Production secrets live in a .env file on one laptop in another country.
• CI is green on a private runner nobody can reach.
• The “repo” is a Drive folder of exports, or a ChatGPT project, or a Lovable/v0 export with no history.
• Legal ownership was never written down. The contractor agreement mentioned deliverables but never named repositories, cloud accounts, or store listings.

You can hire a strong engineer tomorrow and still waste weeks recreating access. You can pay for a full rewrite when a week of ownership recovery would have unlocked a salvageable product. You can also keep shipping on an orphaned stack until a security incident forces your hand.

This post is about that fork in the road: access, ownership, inventory, then an honest call on evaluate vs review vs rebuild.

Why this happens (common patterns)

These situations are more common than founders admit, especially after AI made it cheaper to “spin something up.”

1) Speed-first overseas team with informal handoff

A small team overseas ships features fast. Communication is Slack and Loom. The founder never asks for org-level GitHub ownership because demos look fine. When the relationship ends — budget cut, disagreement, team joins a bigger client — the admin seat leaves with them. The product keeps running on their cloud card for a while. Then the card expires.

2) Solo contractor as single point of failure

One freelance developer builds everything. They own the repos “for convenience.” They own the Firebase project. They own the domain DNS “temporarily.” They are helpful until they are not. There is no malice required for this to become a crisis. People get sick, change careers, or simply stop caring after payment disputes.

3) Agency build with incomplete transfer

An agency delivers a launch. The contract says source code will be transferred. In practice you get a ZIP, a staging URL, and a knowledge-transfer call. Admin rights on production never move. Monitoring stays on their Datadog. When the warranty period ends, you discover you were a guest in your own system.

4) AI-built / vibe-coded product with no engineering owner

A founder or junior builder prompts an app into existence. The first version is impressive. Auth kind of works. Payments kind of work. Then someone needs SSO, multi-tenant roles, App Store review fixes, or a proper data migration. There is no architectural owner. The chat history is the documentation. The “repo” may not even exist in a durable place. This is not a moral failing — it is a new failure mode. AI lowered the cost of starting and raised the odds of orphaned intermediate products.

5) Acquisition or co-founder split without technical escrow

A product changes hands. Equity documents mention IP. Nobody inventories cloud accounts. Six months later the new owners cannot rotate keys because they never controlled the identity provider. Inherited apps fail more often on access than on algorithms.

6) “We’ll tidy ownership after launch”

Launch pressure kills process. Everyone agrees the company will create the org next sprint. Next sprint never comes. Production stays on a personal account because changing it feels risky. That risk compounds quietly until it becomes existential.

None of these patterns require a villain. They require missing ownership design. Ownership is part of architecture, the same way auth and backups are.

What breaks when nobody owns the code

When access and ownership are unclear, several classes of failure show up together.

Security and secrets

If you cannot rotate keys, you do not control security. Former contractors may still have deploy keys. Shared passwords sit in old Slack threads. API keys for OpenAI, Stripe, Twilio, Google Maps, or Firebase remain in client bundles or public repos. An orphaned codebase is often a secrets archaeology project before it is a feature project.

Intellectual property and commercial risk

Customers assume you own the product. Investors assume you own the product. App Store listings assume you own the product. If the source of truth lives under someone else’s account, your commercial story is weaker than your landing page suggests. Even if contracts say IP assigns to you, practical control matters when you need to patch a vulnerability tonight.

App Store and Play Console accounts

Mobile products die in account limbo more often than people expect. If the Apple Developer Program membership is personal, transferring an app is possible but slow and stressful. Push certificates, signing keys, and subscription products all sit behind that identity. React Native apps I ship — for example the fitness products documented in the Di Lorenzo / My Fit Spot case study and feels@home case study — are treated as company assets with company store ownership from the start. That discipline exists because store control is product control.

CI/CD and the ability to ship

If you cannot build and release, you do not have a product team — you have a frozen artefact. Broken CI is not “tech debt.” It is a hard stop on security patches. Orphaned pipelines often depend on secrets in a dead machine, a cancelled Bitbucket minutes plan, or a personal Expo account.

Documentation and tribal knowledge

Missing docs are annoying when the team is present. They are catastrophic when the team is gone. Architecture decision records, data models, known bugs, and “do not touch this cron” notes leave with people. AI-generated code makes this worse when comments are confident and wrong.

Data, backups, and compliance

Where is the production database snapshot? Who can restore it? Which region is PII stored in? If a user requests deletion under privacy law, can you execute it end to end? Inherited apps frequently fail the boring questions before they fail the glamorous ones.

Vendor lock and unpaid bills

Cloud bills on a personal card get cancelled. Domains expire. Email sending domains lose DNS. The product “breaks” without a single line of application code changing.

Week-one checklist: access, ownership, inventory

Founders do not need a six-week discovery programme before they can act. They need a week of disciplined recovery. Here is the checklist I walk people through before any deep evaluation.

Day 1–2: Lock the human and legal surface

1. List every person who ever had admin access. Contractors, agencies, co-founders, interns, “the cousin who helped with DNS.”
2. Find contracts and statements of work. Highlight clauses on IP assignment, source delivery, account ownership, and post-termination access.
3. Freeze outgoing payments that create leverage without creating access. Paying another month for “handover that never arrives” rarely helps. Paying for a short, scoped recovery engagement can.
4. Create a company-owned password manager vault and stop sharing credentials in chat.
5. Decide the company legal entity that should own accounts (Pty Ltd, etc.) so transfers have a destination.

Day 1–3: Recover identity providers and email

6. Company email as the root of trust. If production accounts use personal Gmail, plan migrations carefully. Prefer company Google Workspace / Microsoft 365 identities.
7. Domain registrar and DNS. Confirm who can renew the domain and edit records. Export zone files.
8. SSO / identity for internal tools. If staff still use a contractor’s Okta or Auth0 tenant, flag it.

Day 2–4: Repository and source of truth

9. Find every copy of the code. GitHub/GitLab/Bitbucket orgs, personal forks, ZIP exports, laptop checkouts, AI tool project exports, cloud IDE workspaces.
10. Confirm org ownership, not collaborator access. Being invited as a collaborator is not ownership. Transfer the repository into a company organisation.
11. Preserve history. Prefer transfer over re-upload so you keep commits, issues, and PR context.
12. Enable branch protection and 2FA requirements once you control the org.
13. Inventory monorepos vs multi-repos. Map mobile, API, admin, and infrastructure packages so you know what “the app” actually is.

Day 3–5: Cloud, data, and runtime

14. Cloud accounts: AWS / GCP / Azure / Vercel / Netlify / Railway / Render / Heroku / DigitalOcean. Confirm billing owner and IAM root.
15. Database hosts and backups: managed Postgres, MongoDB Atlas, Supabase, Firebase. Download a backup you can restore independently.
16. Object storage and CDN: S3, Cloudflare R2, Cloudinary, Cloudflare Stream (common on media-heavy fitness products).
17. Serverless and edge functions. Easy to forget; often hold business logic.
18. Logging and error tracking: Sentry, LogRocket, Datadog. Losing these blinds you during recovery.

Day 3–5: Payments, messaging, AI vendors

19. Stripe / RevenueCat / Apple IAP / Google Play Billing. Confirm the company owns the merchant accounts and tax settings.
20. Email/SMS: SendGrid, Brevo, Twilio, Postmark. Check domain authentication (SPF/DKIM/DMARC).
21. AI providers: OpenAI, Anthropic, Azure OpenAI, vector DBs. Rotate keys after you control the apps that use them.
22. Analytics and ads pixels. Not glamorous, but part of the operating surface.

Day 4–6: Mobile store control (if applicable)

23. Apple Developer Program membership — organisation vs individual.
24. App Store Connect roles and transfer eligibility.
25. Google Play Console developer account ownership.
26. Signing keys / credentials for Android and iOS. Without these, “we have the code” is incomplete.
27. Push notification credentials (APNs, FCM).

Day 5–7: Inventory the product itself

28. Write a one-page system map: clients, APIs, jobs, data stores, third parties.
29. List environments: local, staging, production. Note which still exist.
30. Capture known user-facing defects from support tickets — they become evaluation priorities.
31. Identify regulatory or industry constraints (health, finance, children’s data). They change the rebuild-or-ship bar.
32. Decide what “success in 30 days” means: regain deploy ability, patch critical security, keep users stable, or prepare a rebuild brief.

If you complete this checklist and still cannot obtain repository access, treat the product as operationally orphaned even if binaries exist in the stores. Binaries without a maintainable source-of-truth are a liability countdown.

When an AI app evaluation helps vs full rebuild vs code review

Founders often ask for the wrong engagement because the labels sound similar. Here is how I separate them in plain language.

Choose an AI app evaluation when…

• You have (or can recover) enough access to inspect the product, and you need a go / no-go / conditional decision before more spend.
• The product was partly AI-built or vibe-coded, and you do not trust the architecture, auth, or production readiness.
• You inherited an app and need a senior engineer to say what is salvageable vs theatrical.
• Investors or co-founders want an independent technical reading, not a sales deck.
• You are deciding between patch-and-stabilise, staged rewrite, or greenfield.

An evaluation answers product and risk questions: Is this safe to put real customers on? What must change before scale? Where is AI residue creating false confidence?

The live offer page is here: AI app evaluation.

Choose a code review when…

• Ownership and access are already under company control.
• You trust the product direction, but you need a repo-level pass on quality, security, maintainability, and delivery hygiene.
• A team exists and will act on findings; you need actionable defects with severity, not a rebuild strategy memo.

Code review is deeper on the codebase and narrower on product strategy. Details: code review.

Choose a rebuild (often React Native) when…

• Access cannot be recovered in a reasonable window, or recovered code is not a viable foundation.
• Security posture is unrecoverable without rewriting auth and tenancy.
• The stack choice itself is wrong for the business (for example a brittle web wrapper pretending to be a mobile product when you need store-grade subscriptions and offline flows).
• The cost of continuous patching exceeds the cost of a clean rebuild with company-owned accounts from day one.

I rebuild and ship React Native products when that is the honest path — see app development and the fitness case studies above. I do not recommend rebuild because it is more billable. I recommend rebuild when evaluation evidence says the foundation cannot carry the next two years of product risk.

Choose advisory / consultancy first when…

• You do not even know which of the above you need.
• Stakeholders disagree and need a short structured conversation before money moves.

That conversation lives here: consultancy.

How I run an evaluation (honest process)

I evaluate against the same production bar I use on products I actually ship — not against an agency checklist invented for proposals.

Proof that is already public on this site includes:

• Di Lorenzo / My Fit Spot — long-running React Native fitness / nutrition platform work
• feels@home — React Native fitness / membership product with subscriptions and ops tooling
• Hub project management platform — multi-tenant SaaS
• Help and Healing — production WordPress site for a healthcare practice
• AI Business Intelligence Dashboard — multi-source analytics with AI summaries operators can act on

I am one engineer. You talk to me. I read what you shipped. More about how I work: About Muhammad Adil.

Step 1 — Scope what “ready” means for you

“Production ready” is not universal. A closed beta for 50 users is different from App Store launch with paid subscriptions. We agree the decision you need: ship, pause, patch, or rebuild. We also agree access constraints up front. If you cannot provide repo access yet, the engagement may start as an ownership-recovery advisory plus black-box product review, then deepen when access arrives.

Step 2 — Access and inventory gate

Before deep architecture opinions, I verify what we can actually inspect:

• Repository (or artefacts)
• Staging / production walkthrough
• Environment configuration (without pasting secrets into chat)
• Store listings and release channels if mobile
• Third-party admin access where relevant

If the gate fails, the first deliverable may be the week-one checklist above, not a pretend architecture score.

Step 3 — Architecture and AI residue

I look at stack fit, module boundaries, data model honesty, and leftover scaffolding from AI generation. AI residue includes generated folders nobody owns, duplicated auth flows, placeholder security middleware, hallucinated config, and “demo” patterns that shipped by accident. I also look for the opposite problem: a thin AI feature glued onto an otherwise fine app in a way that creates privacy or cost risk.

Step 4 — Auth, tenancy, and abuse paths

Who can become whom? Are tokens stored safely on device? Are admin routes protected server-side? Multi-tenant products get special scrutiny because one bug becomes many customers’ data. Hub-style SaaS work makes me allergic to “filter by companyId in the client only” designs.

Step 5 — Security hygiene and secrets

Dependency risk, secret sprawl, insecure direct object references, file upload paths, webhook verification, CORS mistakes, and logging that leaks PII. I am looking for launch blockers and near-term incidents, not a perfect OWASP theatre report.

Step 6 — Operability: deploy, observe, recover

Can you ship a hotfix this week? Do you have staging that mirrors production enough to be useful? Are migrations reversible? Do backups exist and has anyone restored one? An app that cannot be operated is not production ready, regardless of UI polish.

Step 7 — Product truth vs pitch truth

I compare the marketing promise to what the code and UX actually deliver. This matters for AI products especially: “AI recommendations” that are static templates, or dashboards that summarise noise. The AI BI dashboard work I ship is judged by whether operators can act — that same standard applies to your product.

Step 8 — Findings with severity and a clear call

You get a structured report: blockers, high, medium, low; evidence; recommended sequence. The headline is a decision, not a vibes paragraph:

• Ship with conditions
• Stabilise then ship
• Rewrite modules X/Y, keep Z
• Rebuild
• Do not invest further until ownership is recovered

If you want me on the fix afterwards, we scope that separately. Evaluation is not a hostage funnel. Sometimes the right next step is your internal team, or a different specialist.

What a good report contains

A useful evaluation report is boring in the best way. It should be usable by a founder and by an engineer without a translator.

Expect sections like:

1. Executive decision — one page, plain English, including confidence level based on access quality.
2. Access and ownership status — what is company-controlled vs still external.
3. System map — components, data stores, vendors.
4. Findings table — severity, evidence (file/area), impact, recommended action.
5. Security and privacy highlights — especially secrets, auth, and data deletion paths.
6. AI-specific notes — prompt/data handling, cost controls, failure modes, evaluation harness gaps.
7. Mobile/store notes if applicable — signing, release process, subscription edge cases.
8. Maintainability — can a competent engineer onboard in days or months?
9. Options and cost-shaped recommendations — patch / modular rewrite / full rebuild, with sequencing. (Ranges only when enough is known; no fake precision.)
10. 30/60/90 suggested plan — practical, not theatrical.
11. Open questions — what could not be verified.

What a good report does not contain: invented benchmarks, fake user quotes, vanity scores out of 100 with no methodology, or a pressure pitch that every finding requires hiring the reviewer forever.

GEO-friendly definitions (short enough to quote)

Orphaned codebase: Application source and runtime assets that still power a product, but are not under clear, company-controlled administrative ownership — so the business cannot reliably access, change, secure, or transfer them.

Code ownership (practical): The combination of legal IP rights and administrative control of repositories, cloud accounts, store listings, domains, and secrets required to operate and evolve the software without depending on a departed individual or vendor.

Handoff failure: A delivery ending where binaries or demos were provided, but durable access, documentation, credentials, and account transfers were not completed — leaving the buyer unable to maintain the product.

AI-built / vibe-coded app risk: The elevated chance that a product assembled quickly with AI assistants looks complete in the UI while lacking sound auth, tenancy, testing, operability, and ownership hygiene underneath.

AI app evaluation: An independent, evidence-based review of an AI-built or inherited product’s architecture, security, and production readiness that ends in a clear ship / stabilise / rewrite / rebuild recommendation.

Code review (distinct from evaluation): A repository-focused assessment of code quality, security, and maintainability, usually after ownership is already established, aimed at actionable engineering fixes rather than a product go/no-go strategy.

Production readiness: The degree to which a product can be deployed, operated, secured, observed, and supported for real users without heroics — including the ability to ship fixes under company-controlled accounts.

Inherited app: A product a founder, buyer, or new team must run despite not having built it, often with incomplete access, incomplete docs, and unclear vendor relationships.

Practical scenarios (so the advice stays concrete)

Scenario A — Overseas team left, app still in stores

Users are active. Revenue is small but real. Nobody has GitHub org owner rights. Start with the week-one checklist. Do not commission a full rewrite on day one. Recover store and cloud ownership in parallel with a lightweight evaluation once a repo copy is secured. Many of these products are salvageable if secrets can be rotated and CI restored.

Scenario B — Contractor delivered an AI MVP, then vanished

You have a staging URL and a Notion doc. No tests. Auth is email magic links with a shared admin. Here evaluation matters early, because “keep building features” will multiply debt. Often the right call is: freeze feature work, recover accounts, evaluate, then either harden a thin vertical slice or rebuild the auth/data core before anything else.

Scenario C — You can access the repo, but nobody trusts it

This is classic code-review territory after a short evaluation framing. If ownership is clean, skip theatrical strategy and get severity-ranked defects your team can burn down. Use evaluation language only if the business decision is still “should we continue this product line at all?”

Scenario D — React Native app with broken release train

If signing keys and store accounts are recoverable, restoring the release train can unlock months of product life. If keys are gone and the codebase is a maze of abandoned native modules, a React Native rebuild under company accounts may be cheaper than archaeology. That call should be evidence-led — which is exactly what an evaluation is for.

What founders should stop doing

• Stop treating ZIP files as handoff. Demand org transfers.
• Stop paying for more features on an unowned stack. You are decorating a house you do not have keys to.
• Stop equating a pretty UI with production readiness. Especially with AI demos.
• Stop hiring five people to “take over” before one senior person maps ownership. Headcount does not replace access.
• Stop publishing security claims you cannot verify. Inherited apps sometimes claim SOC-ish language with no controls.

What good ownership looks like going forward

If you are starting clean — or restarting clean after a painful recovery — bake ownership into the build:

• Company-owned Git organisation with 2FA and least privilege
• Company-owned cloud and database projects
• Company-owned Apple/Google developer accounts
• Secrets in a managed store, rotated, never in chat
• Infrastructure as code where it pays for itself
• A one-page architecture note updated when decisions change
• Staging that can accept real fixes
• A documented release path someone else could follow

This is how I treat products I ship. It is not bureaucracy. It is how you avoid becoming the cautionary tale in someone else’s blog post.

FAQ

What if we literally have no repository access?

Then your first project is recovery, not features. Use contracts, provider support processes, and any devices that still hold checkouts. An evaluation can still assess the running product externally, but confidence will be lower, and the report should say so. Sometimes the honest recommendation is rebuild because recovery timelines exceed business risk tolerance.

Can you evaluate without source code?

Partially. You can review UX, API behaviour, store presence, headers, basic security posture, and operational symptoms. You cannot responsibly sign off on architecture or maintainability without code. I will not pretend otherwise.

Is an AI-built app automatically unsafe?

No. AI can accelerate competent engineering. The risk appears when AI output ships without ownership, review, tests, and an engineer accountable for production behaviour. The tool is not the villain; missing engineering ownership is.

How is AI app evaluation different from code review?

Evaluation decides whether the product should be trusted as a foundation and what strategic option to take. Code review inspects the repository for actionable quality and security issues once you are committed to working in that codebase. Many clients need evaluation first, then review or rebuild.

Do you rebuild React Native apps yourself?

Yes, when that is the right path. I ship React Native products end to end — planning, implementation, store release — as a solo engineer. See app development and the Di Lorenzo / feels@home case studies. I will not push a rebuild to win a larger contract if stabilisation is enough.

Will you work with our overseas team if they return?

If they return with proper company-owned access and clear roles, yes where it helps. I am not anti-remote or anti-overseas talent. I am anti-unowned production systems. Geography is not the failure mode; accountability design is.

How long does an evaluation take?

It depends on access quality and product size. A focused prototype review is much shorter than a multi-surface production system with mobile, API, and admin. We agree scope before I start. If access archaeology dominates, we split recovery advisory from deep technical evaluation.

What do you need from us to start?

A decision owner on your side, whatever access you currently have, the business outcome you need in the next quarter, and honesty about known gaps. Contact details and next steps: contact or book a short call via consultancy.

Soft next step

If your overseas team left, your contractor disappeared, or you inherited an AI-built app with unclear ownership, do not start with a vanity rewrite pitch. Start with access, ownership, and an honest technical reading.

I run AI app evaluations myself against the same bar as products I ship — Di Lorenzo / My Fit Spot, feels@home, Hub, Help and Healing, and the AI BI dashboard. If the next step is a repo-level pass, use code review. If the evidence says rebuild mobile properly, use app development.

Talk to me directly: https://madil.com.au/contact/ · consultancy · about.

I usually reply within one business day. Bring whatever access you have — even if the answer today is “we are not sure who owns the repo.” That uncertainty is exactly when a careful evaluation earns its keep.