Buying a micro-SaaS? Ask for a working handover.

Buying a micro-SaaS should let you deploy it, recover its data, and run its essential services under the agreed ownership. Before the handover, ask for evidence of those operations. A repository invitation proves only one part of that work.

I review code and security through Thunkle. This checklist covers the technical questions to settle when taking over a product. It does not assess the deal's valuation, legal rights, tax treatment or financial claims. Those need their own checks and advisers.

Build the asset list around what the app needs to do

Start with a short walkthrough: a customer signs up, completes the main workflow, pays and comes back later. List each service involved. Then cover what happens without the customer present: scheduled jobs, billing updates, email, backups and alerts.

For each dependency, record the owning account, who can administer it, how it will transfer and what remains dependent on the seller. Do not assume one platform's transfer moves connected accounts on other platforms.

GitHub, for example, says repository webhooks, secrets and deploy keys remain associated after a repository transfer. It also says the original owner becomes a collaborator. That makes an access review part of handover, not something the repository rename proves complete. GitHub repository transfer documentation.

The technical handover acceptance sheet

Copy this table and add an owner, evidence link and review date to each row. These are proposed acceptance checks, not results from a completed acquisition.

Mark a row verified only when its agreed test has been observed. Keep “not tested”, “blocked” and “not applicable” separate. An unresolved question is manageable when it has an owner and a plan; hiding it behind a completed checkbox is less useful.

Run one clean deployment before relying on the instructions

Have the receiving developer follow the documented process without relying on the seller's machine. Record the commit, runtime, dependency lockfile, environment-variable names and the deployment produced.

Keep real payment actions, messages and scheduled jobs disabled unless a safe test procedure has been agreed. Then run the product's essential flows with test identities. Include a denied action, such as a user trying to open a record belonging to a different workspace, alongside the successful customer path.

If the build fails, record the actual dependency instead of asking the seller to fix it quietly on their laptop. The purpose is to produce instructions the next operator can repeat.

For an app tied to a builder, this test may still use that builder's backend. Document the dependency rather than implying that possession of source code removes it. The platform migration worksheet is useful if the intended handover also includes a move to different infrastructure.

Ask for restore evidence, not just a backup setting

A useful restore record identifies the backup, destination, time taken, records checked and excluded systems. File attachments, identity providers and encryption material may need separate treatment.

Supabase's documentation states that its database backups do not contain objects stored through the Storage API. A successful database restore therefore does not demonstrate recovery of those files. Check the equivalent boundary for every provider the product uses. Supabase backup documentation.

Run the rehearsal in an authorized isolated environment. Protect customer data, block outbound side effects and agree how temporary copies will be deleted. If a rehearsal is not possible before handover, label recovery unverified and record the remaining work. Do not convert “backups enabled” into a tested recovery claim.

Put recurring costs beside their operational purpose

A low hosting invoice can omit services paid through a founder's personal account or a temporary credit. Build an inventory from the service accounts and billing records made available for review. This is an operational dependency check, not a financial audit or a valuation model.

Capture billing periods and currency separately when comparing invoices. Describe a traffic scenario before estimating future usage. Do not multiply a current invoice by a user-growth factor and present the result as a reliable forecast.

Finish with an operating handover

Agree who handles an incident during the transfer window, who removes unnecessary access and when, and what support is included afterwards. Ask the receiving operator to locate a failed job, follow a rollback procedure and identify the person to contact for a provider problem.

A concise final record can look like this:

Asset / workflow:
Receiving owner:
Test date and environment:
Evidence reference:
Status: verified / blocked / not tested / not applicable
Known limitation and practical consequence:
Next action, owner and deadline:
Accepted by:

The final record should explain what the buyer can operate and what remains unresolved. It need not be an elaborate document, but it should survive the last handover call.

If you need an independent developer to examine the code and the technical handover, ask about Thunkle's inherited-codebase review. I can scope the checks around the application and the decisions you need to make. Legal ownership, contractual transfer and financial due diligence remain separate work.