How to Evaluate a Software Company Taking Over an Existing App?

Why is an app takeover different from new development?

An app takeover is not simply receiving the code of an existing product; it is the process of making current technical debt and operational responsibilities visible. In a new development project, scope is defined around future work, while a takeover must first verify the system's current condition. Committing to scope or timing before reducing these unknowns can create a misleading comparison between candidates.

What approach should you expect in the first meeting?

A candidate should preferably propose reviewing the source code, environments, store accounts, third-party services, and bug records before giving a development schedule. For a broader comparison framework, the guide to technical capability, proposal, and support criteria for mobile app companies can also help. The first deliverable of a takeover should be a verified current-state assessment, not a new feature list.

• Make the current architecture and technology stack visible
• Separate working modules from problematic ones
• Verify access rights and account ownership
• Identify critical security and version risks
• Separate urgent maintenance from planned development requests

Program testing can be used to show the presence of bugs, but never to show their absence!- Edsger W. Dijkstra

Which access rights should be prepared before takeover?

The access rights prepared before takeover should cover every technical asset that affects how the app operates and is published. The source-code repository, server or cloud environment, database, App Store and Play Store accounts, domains, API keys, notification services, analytics tools, and error-monitoring systems should be collected in a single handover inventory.

How should the handover inventory be organized?

The inventory should not be just a list of usernames and passwords. It should identify the owner of each asset, the permission level, who manages it, how it relates to production, and whether access transfer is complete. Passwords should be shared through secure password managers or another company-approved secure channel, and critical services tied to personal accounts should be moved to corporate accounts where practical. The inventory should also explain what each permission enables so the incoming team can avoid unnecessary access and reduce discovery friction.

• Git repository and primary branch structure
• Backend, database, cloud, and backup access
• Apple App Store Connect and Google Play Console permissions
• Push notification, email, SMS, and payment services
• Analytics, crash reporting, and log monitoring tools
• DNS, domain, SSL, and CDN management

How should code condition be assessed in the first review?

The first technical review should not end with a vague judgment that the code is “good” or “bad.” It should assess observable criteria such as whether the project can be built, how it is structured, dependency condition, test coverage, security risks, and release readiness. The candidate should be able to run the project in its own environment, test critical flows, and classify factors that make maintenance difficult. Where access is available, the backend, API contracts, database changes, and deployment automation should be reviewed as part of the same technical system.

What concrete outputs should the code review produce?

The review should check whether the app builds, whether dependencies are current, whether secrets are embedded in code, how errors are handled, how architectural layers are organized, what tests exist, and how deployment works. The guide to evaluating code quality, testing, and source-code delivery can help compare candidates against the same technical categories. Each risk should be documented with its severity and a recommended action.

• Ability to install and build the project in a clean environment
• Status of critical dependency and framework versions
• Automated testing coverage and manual testing needs
• Security weaknesses and secret-management practices
• Logging, error handling, and observability maturity
• Repeatability of release and deployment steps

Who should own publishing accounts and critical assets?

Publishing accounts and digital assets that are critical to app continuity should remain under the company's corporate control whenever practical. The software provider can work through assigned roles and permissions, but store accounts, production servers, domains, analytics properties, and core service subscriptions should not depend solely on a vendor employee's personal account. Separating ownership from day-to-day working access helps reduce disruption if the provider changes again.

What should be checked for app store accounts?

On the Apple side, review the source-code handover and publishing-rights controls for iOS; on Android, verify ownership of the publishing account and signing key. Even if the development team changes, the company should retain the ability to publish the app, revoke access, and grant new permissions without depending on the outgoing provider.

• Corporate ownership of store accounts
• Secure storage of signing keys and certificates
• Role-based access to production environments
• Visibility into billing and service subscriptions
• Controlled removal of former team accounts

How should urgent maintenance and new development differ?

Urgent maintenance and new development should not be managed in the same undifferentiated queue. Outages, security vulnerabilities, store rejections, critical integration failures, or risks of data loss require operational priority, while new screens, features, and experience improvements belong in a separate product-development plan. This separation also clarifies spending because the business can distinguish stabilization effort from investment that adds new product value.

How can a prioritization model be structured?

During the initial takeover period, bug records can be classified by impact and urgency. Maintenance capacity and product-development capacity can then be allocated separately so new requests do not delay critical fixes. The guide to comparing version management, testing scope, and technical support can help determine how each candidate manages this separation. Every request should have a category, impact level, priority, and approved scope.

• Level 1 critical outages and security issues
• Level 2 high-impact defects that break core functions
• Level 3 fixes with limited user impact
• Planned maintenance and version-compatibility work
• New feature and product-development requests

How should unknown technical risks appear in proposals?

Unknown technical risks should not be hidden inside one fixed number without explanation. The proposal should state what has been verified, what remains unknown, and which assumptions were used for pricing and scope. In takeover projects, inaccessible services, missing documentation, outdated dependencies, or unknown production issues may only become visible after the initial review. A useful proposal therefore explains how uncertainty will be reduced and when re-scoping may be required.

How should the risk report connect to the proposal?

A sound proposal separates known work into a defined scope while identifying conditions that still require investigation, the mechanism for additional work, and the approval process for changes. This lets the business see the risk while preventing the provider from making broad guarantees about a system it has not fully verified. Uncertainty should be made manageable rather than concealed.

• Verified technical findings
• Areas that could not be verified because access is missing
• Critical risks and the recommended improvement sequence
• Technical and operational assumptions used in the proposal
• How scope changes will be approved
• Dependencies that require additional investigation

Why should review and maintenance proposals be separate?

Separating the technical review from the long-term maintenance and development proposal creates a more reliable comparison, especially when code condition is unknown at the start. The first phase can be a limited mobile-app technical audit; the second phase can use verified findings to plan maintenance, version updates, bug fixes, and development capacity. This also lets maintenance providers scope work from shared evidence instead of building large contingencies around assumptions.

How can a two-stage proposal be structured?

The first proposal can deliver an access review, application code review, risk register, and prioritized action recommendations. The later app-maintenance service should define the operating model, service-level agreement (SLA), response scope, version management, and development-request process. For a related comparison, review how App Store publishing, maintenance, and version updates are structured in proposals.

• Phase 1 access and technical-state verification
• Phase 1 risk, technical-debt, and priority report
• Phase 2 maintenance and incident-response model
• Phase 2 version, testing, and store-release process
• Phase 2 new-development request and approval flow

Which criteria should be used to compare providers?

Candidate software companies should be compared by takeover methodology and risk-management discipline, not only by hourly rates or team size. A useful evaluation considers the quality of the technical review, responsibility boundaries, access security, documentation, testing approach, communication routines, and measurability of the maintenance process within one framework. It can also examine whether the team has taken over comparable technology stacks and how it handles critical production systems.

What should you ask during comparison meetings?

Ask every candidate the same core questions: What will you verify first, how will you proceed if the project does not build, how will you report unknown risks, how will urgent issues be handled, and how will new development be planned? Turning these answers into written proposal and process language, rather than relying on verbal promises, makes meaningful differences between candidates easier to see.

• Takeover and technical-discovery methodology
• Code-quality and security-review approach
• Testing, release, and store-publishing experience
• Clarity of SLA and emergency-response processes
• Documentation and knowledge-transfer discipline
• Scope and change management for new development

How should controlled technical discovery and handover start?

A controlled takeover should begin by organizing access and then giving candidate firms the same technical-discovery scope. This allows each firm to review comparable information, report risks from the same starting point, and produce proposals that are easier to compare. The business can also avoid sharing critical accounts indiscriminately by using an authorized and traceable process. Where possible, early discovery should use read-only or limited roles, with production changes subject to separate approval and access activity kept auditable.

A practical checklist before the first review

List the source code, store accounts, server environments, service subscriptions, and bug records in one place; identify access owners; and verify backups for critical production information. Then ask candidates to document their review scope, expected report, assumptions, urgent-maintenance approach, and the maintenance-development model they would propose afterward. The objective is not merely to move the app from one company to another, but to strengthen the business's technical control and establish a sustainable operating model.

• Complete the access and asset inventory
• Verify corporate ownership of critical accounts
• Classify the current bug and request backlog
• Share the same technical-discovery scope with candidates
• Compare risk reports and downstream proposal structures
• Plan the permission transfer and removal of old access