A SaaS acquisition can look finished while the buyer still depends on the seller for ordinary operations. The repository has moved. The agreement has been signed. The new owner can see the dashboard. Then a deployment fails or a payment webhook stops working. The seller is still the only person who can fix it.

The mistake is treating source code as the product. Source code explains how an application works. It does not prove who controls the system running it. If you are still deciding whether to proceed, begin with the technical review before buying a micro-SaaS. This article deals with the narrower ownership question.

Map the production chain

A small SaaS normally rests on several independent services: source control, deployment, domains, DNS, databases, authentication, email delivery, payments, monitoring and third-party APIs. Every service has its own owner, administrators, recovery email, billing relationship and access tokens.

The buyer needs control of the whole chain. If one critical link remains in the seller's personal account, the handover is incomplete even when the application appears healthy.

Start by identifying the production path. Which repository creates the production deployment? Which Vercel or cloud project receives it? Which domain points to that project? Where does the application read and write its data? Which provider sends password resets? Which account receives subscription revenue?

That path shows what can actually stop the business. A generic list of logins does not.

Test what the invitation allows

A collaborator invitation may be enough during the transition. By the end, the buyer should be able to remove the seller without breaking production. GitHub distinguishes repository access from the steps required to transfer a repository, while Vercel documents a separate project-transfer process. Completing one does not silently complete the other.

For each critical service, check four things:

  • The buyer controls the organisation or primary account.
  • Billing and recovery details belong to the buyer.
  • The buyer can add and remove administrators.
  • The seller's personal access can be revoked after a defined transition period.

If the service cannot transfer ownership cleanly, document the workaround before closing. Sometimes a new account must be created and the application migrated. That is operational work, not a detail to discover after payment.

Hidden dependencies live outside the repository

Configuration often reveals more than the code. Environment-variable names can expose services for email, analytics, storage, payments and AI APIs without revealing their secret values. Deployment settings, DNS records, webhooks and scheduled jobs reveal another layer.

Build the inventory without collecting passwords in a spreadsheet. Each dependency needs an accountable owner and evidence that the buyer can control it.

Test the business after the transfer

A successful login is not enough. Run the actions that keep the product alive:

  • Deploy a harmless change from the buyer-controlled repository.
  • Create and reset a test-user password.
  • Confirm transactional email reaches the inbox.
  • Test a database read and write.
  • Trigger a payment event in the provider's test mode.
  • Confirm scheduled jobs and webhooks still run.
  • Verify monitoring alerts reach the buyer.

Record the result, the account used and the time of the test. A screenshot alone is weak evidence; it rarely proves which organisation or permission level produced it.

Define what complete means before closing

A clean handover has a clear finish line: the buyer controls the production chain, critical credentials have been rotated, seller access is removed or explicitly time-limited, and the operating checks pass.

A week after closing, the buyer should be able to deploy, recover an account and respond to an outage without calling the previous owner. That is the practical test of whether the software business changed hands.

The small-SaaS acquisition guide places this control test inside the complete buying process. When accounts start moving, use the transfer-day handover checklist, then record the result in the SaaS Transfer Control Register.