Technical due diligence for freelancer-built products

Why handover fails after the deal

A product built by a freelancer can look stable and still be one missing login away from trouble. The code may sit in a repository, the app may be live, and customers may be paying. None of that proves a new owner can keep it running next week.

The usual problem is simple. One person carries the whole system map in their head. They know which server runs the worker, where DNS lives, which old script handles backups, and which inbox gets outage alerts. That knowledge often never reaches the docs. When the deal closes, the buyer gets files, but not the habits, shortcuts, and hidden dependencies that keep the product alive.

Access gaps are even more common. Buyers may receive source code and still miss the cloud account, domain registrar, app store account, email service, error tracking, or CI secrets. A product can keep working for a while with those gaps. Then an SSL certificate expires, a mobile build needs a new release, or a payment webhook breaks after an API change. Suddenly the team owns the business, but cannot ship a fix.

That is why diligence on freelancer-built products has to go past the repository. Running software is not the same as transferable software.

Short deal timelines make this worse. In a rushed review, buyers often watch a demo, skim the codebase, and ask, "Is everything documented?" The seller says yes, and the process moves on. That misses the real risk. You do not learn continuity from promises. You learn it by checking whether another person can log in, deploy, roll back, and recover without the original builder.

A small SaaS can survive rough code for quite a while. It usually does not survive missing control. If ownership, deployment access, and daily operations stay tied to one freelancer, the handover can fail even when the product itself looks healthy.

What the short audit needs to answer

A short audit should answer one practical question: can the buyer own and run the product the day after closing, even if the original freelancer stops replying?

Start with ownership, not code quality. Find out who owns the source code, design files, production data, domain, cloud account, app store profiles, email sender, analytics, and paid API accounts. If any part still lives in the freelancer's personal account, the buyer does not fully control the product.

Then check whether a new team can ship a fix this week. Who can open the repo, read the docs, get into the hosting account, change secrets, and deploy a small patch? If one person still needs a private laptop, a local SSH key, or memory of a hidden step, continuity is weak.

Billing control matters more than many buyers expect. You need to see who pays for hosting, who can update the card, who can recover the account, and who gets outage or renewal emails. A product can run for months and still fail suddenly because the wrong person owns the billing profile.

The audit should also expose the first likely break if the freelancer disappears. In small products, it is often something ordinary: the domain renewal email goes to the freelancer, CI secrets live on one machine, backups run but nobody tests restores, production alerts go to an old inbox, or a paid third-party service has no shared admin access.

Trust is not enough in an ownership audit before acquisition. Ask for proof: signed IP transfer terms, admin screenshots, billing owner details, registrar records, repository permissions, and recovery methods for MFA and email. A clean answer is not "the freelancer handles it." A clean answer is "this account is ours, these people can access it, and this document proves it."

If the seller cannot prove those basics in a short window, the risk is not abstract. It is operational, and it usually shows up right after closing.

A 3-day audit plan

Three days is enough to spot most deal-breaking gaps if you test control, not just code quality. The fastest useful audit follows the path of ownership, release, and takeover.

Do not spend the first day reading random files. Start with the assets that keep the product alive and the people who can lock you out.

On day 1, collect every repo, cloud account, domain registrar login, app store listing, email service, analytics tool, payment account, and error tracker. Match each one to a named owner, admin, and billing contact. If the seller says, "the freelancer handles that," treat it as a risk until you see access.

On day 2, follow one real release from a code change to production. Ask who approves the merge, who runs the deployment, where secrets live, and who can roll back a bad release. Then hand the setup notes to another developer and watch them try to run the app, tests, and deploy flow without help. That single exercise exposes weak handover points fast.

On day 3, write down every missing login, shared credential, undocumented step, and person-dependent task. Group them by deal risk. Can this block operations on day one, slow the new team for a week, or create a legal ownership problem later?

A small SaaS can look tidy in a demo and still fail this audit. One common pattern is easy to miss: the code sits in GitHub, but the production server runs from a freelancer's private cloud account, the domain renews on their card, and the iOS app listing uses their personal Apple ID. The buyer does not own the business until the buyer controls those points.

If time is tight, be strict about evidence. Screenshots, admin invites, billing records, deployment logs, and a successful fresh setup tell you more than promises do. A short audit works best when someone keeps it practical and pushes for proof.

Check ownership before you read code

A clean codebase means little if the seller cannot hand it over. Ownership often breaks in small places: a freelancer kept the repo in a personal account, a domain sits under an old email address, or production depends on a paid template the company never had rights to use.

Start with contracts, statements of work, and change orders. You want plain language that says who owns the code, designs, scripts, and deployment files after payment. Check for carve-outs too. Many freelancers reuse snippets, starter kits, or internal tools across clients. That is fine if the contract allows it and the product does not depend on something the buyer cannot keep.

Unpaid work needs extra care. If a contractor delivered features but the last invoice is still open, ownership may not have transferred yet. That can turn into a real dispute after closing.

Then match the legal owner across every account that keeps the product alive. Look at git hosting, package registries, build secrets, the domain registrar, DNS, SSL certificates, cloud accounts, email tools, error tracking, and billing records for paid services.

Names matter here. If the seller is a company, but the AWS bill, GitHub org, and domain registrar sit under three different personal accounts, you do not have a tidy handover. You have a collection of favors and old logins.

Private dependencies often cause the worst surprise. A repo may build only because it pulls packages from a freelancer's private registry or uses a premium plugin tied to their personal license. Ask the seller to prove that a buyer-controlled account can access every dependency without calling the original developer.

Check third-party code with the same care. Open source libraries are usually simple, but templates, UI kits, icon packs, and commercial components may limit resale, sublicensing, or transfer. If the product includes one of those assets, read the license terms instead of assuming the purchase covers them.

When ownership is real, the paper trail lines up with the access list. If it does not, stop reading code for a moment and fix that gap first.

Trace the release path

Most buyers inspect the code first and miss the part that keeps the product running every week. The release path often tells you faster than the code whether a new owner can take control.

Ask for one live walkthrough of a normal release. The seller or developer should show the full path from a merged change to production: who starts the deploy, where the pipeline runs, which checks happen, and how they confirm the release worked. A real walkthrough beats a verbal summary every time.

Write down every system that holds access or trust for that release path. In small freelancer-built products, secrets often end up scattered across personal laptops and old accounts. Source control, CI/CD tools, cloud servers, registries, DNS, CDN, domain accounts, secret stores, environment files, API tokens, signing keys, and mobile app store accounts all matter here.

Then confirm who can actually approve and run deployments today. If one freelancer has the only working access, you have a continuity problem, even if the seller owns the company and the code repository. The same goes for a private SSH key on one laptop, a build script on one desktop, or a production server that nobody else can enter.

Rollback matters just as much as release. Ask them to show the exact steps for reverting a bad deploy, restoring a backup, and checking the database after a failed migration. If they cannot explain the last rollback they performed, expect trouble when the first post-deal release goes wrong.

Database access needs its own check. Find out who can run migrations, who can take backups, where backups live, and whether the buyer can restore them without calling the old developer. Many handovers fail here, not in the app code.

If the product ships iPhone or Android apps, verify control of the Apple and Google accounts early. A buyer can own the code and still get stuck if updates depend on a freelancer's personal developer account or signing certificate.

A good rule is simple: if a new engineer cannot ship a small fix in the first week after closing, the release path is still owned by someone else.

Test whether a new team can take over

The fastest way to judge continuity is to hand the product to a developer who has never seen it before. Give them the current setup notes, the access list, and one small task. Then watch where they stop.

Ask that developer to do three things in order:

1. Run the app locally or in a test environment.
2. Change one safe setting, such as an email sender name or feature flag.
3. Ship a tiny fix through the real deployment path.

This drill tells you more than a long code review. If the developer gets stuck at step one, the handover is weak. If they can run the app but cannot deploy, the seller still controls the product in practice.

Write down every question they ask. Missing environment variables, unclear secrets, unknown scheduled jobs, and comments like "ask the freelancer" all reveal hidden dependence on one person's memory. That matters as much as code quality.

Support work belongs in the same test. Ask the developer to find a recent error, check the logs, and confirm where alerts go. If nobody can see failures without messaging the former builder, the new team will lose time on basic support.

A simple setup is enough if it works. Server logs, error tracking in a tool like Sentry, and a shared alert inbox can cover most small products. The point is not fancy tooling. The point is whether a new team can spot a problem, trace it, and fix it on their own.

Time the exercise. A small product in decent shape usually lets a capable developer finish this in a few hours. A week of blocked steps means the buyer is inheriting undocumented process, not just software.

One number helps: count how many times the new developer needs private knowledge that is not written down anywhere. That number tells you whether you are buying an asset that a team can run, or renting one freelancer's memory.

A simple example from a small SaaS deal

A buyer looks at a small SaaS that one freelance developer built over two years. The product has paying users, the demo is smooth, and the code in GitHub looks clean enough. At first glance, the deal feels low risk.

Then the audit moves past the repo. The app reads and writes to a production database that sits in the freelancer's cloud account. Backups go to the same account. DNS and email alerts live there too, so the buyer can inspect the code but still cannot run the service alone.

Deployments look fine as well, until someone asks who can ship a fix on Friday night. The release pipeline runs through a private CI setup owned by the freelancer, and it uses personal access tokens created under that person's name. If the handover slips, the buyer gets a product that works but cannot change.

A short review should test control, not just code quality. In this case, the buyer asked for four live checks: access to the cloud project that holds the database, proof that backups can be restored by someone other than the freelancer, CI secrets moved out of personal accounts, and one small production fix deployed by the buyer's own operator.

That last step changed everything. The new team could open the repo, make a tiny change, and pass review. But they could not trigger the release without the freelancer's token, and they could not roll back with confidence because they had no direct database access. The demo was real. The takeover path was not.

Clean code helps, but clean code does not give you custody of the business. If one person still owns the database, the pipeline, and the credentials, that person still controls the product.

Mistakes buyers make in rushed reviews

The most common mistake is simple: buyers read code samples and skip ownership checks. A clean repo can feel reassuring, but code alone does not keep a product running. If the freelancer controls the cloud account, domain, deployment pipeline, and secrets, the buyer does not control the business yet.

Buyers also trust screenshots too easily. A screenshot of a hosting dashboard, app store account, or payment setup proves almost nothing. Ask for live access checks instead. You want to see who can log in, who gets password reset emails, who holds billing control, and who can change production settings without asking anyone else.

Another bad habit is accepting vague promises about handover after closing. If the seller says, "we'll transfer everything later," treat that as risk, not reassurance. People get busy, contractors disappear, and small disputes turn into long delays. Put the transfer steps on paper before the deal closes, with a named owner for each account.

Rushed reviews also ignore the systems around the app. That is where many deals break. The product may depend on an app store account, Stripe or another payment account, DNS, transactional email, SMS, analytics, or a support inbox tied to the freelancer's personal address. If even one of those stays in the wrong hands, the new owner can lose sales, password resets, or update rights.

Missing documentation is another issue buyers wave away. They should not. If nobody wrote down environment variables, server setup, release steps, cron jobs, and renewal dates, a new team wastes days guessing. In a small SaaS deal, that can mean failed deploys on day one.

Good diligence here is less about admiring code and more about testing control. If a new team cannot deploy, bill customers, ship updates, and recover access on its own, the handover is not ready.

A quick check before you sign

These deals often fail on access, not code quality. A product can look stable in a demo and still become hard to run the day after closing if the wrong person holds the passwords, billing, or deploy rights.

Start with ownership. The Git repository should belong to the company selling the product, not a freelancer's personal account. Use the same standard for the cloud account, domain registrar, email service, app store accounts, and payment tools. If any of them sit inside a personal login, you do not fully control the product yet.

A short pre-sign check can stay simple:

1. Confirm the repo owner matches the seller and that admin access can move to the buyer.
2. Check where cloud, domain, and billing access live. Personal cards and private email logins are a bad sign.
3. Ask another developer, not the original freelancer, to set up the project from scratch and push a small change.
4. Verify that backups, logs, and rollback steps work outside a slideshow or verbal promise.
5. Get a written handover list that names each system owner, account, and transfer step.

That third point matters more than most buyers expect. If a fresh developer cannot install the project, load the environment variables, run tests, and deploy a tiny text change, continuity is weak. The product may still work today, but the team change risk is high.

Do the same with operations. Ask the seller to show one recent backup, where logs live, and how they would undo a bad release. Five quiet minutes in a real console tells you more than a long technical call.

A written handover list closes the gap between "we have access" and "we can operate this on day one." Names, roles, accounts, and transfer dates should all sit on one page. If the seller resists that level of clarity, treat it as deal risk, not paperwork.

What to do when you find gaps

One rule saves a lot of pain: sort every gap into either a deal breaker or a first-month fix. Missing proof of code ownership, cloud access, domain control, or release access can stop the deal. Weak docs, old packages, or a messy staging setup usually do not.

A simple filter helps. Stop and resolve the issue before closing if the seller cannot prove IP ownership, transfer admin access, or show who controls production. Treat it as a first-month fix if your team can take control on day one and the risk is mostly speed, not ownership. Push for access transfer before closing whenever possible, while the seller and any freelancers still reply quickly. If the gap creates real takeover risk, tie part of the payment to a clean handover.

That last point matters more than many buyers think. If releases depend on one freelancer's laptop, or if the only backup lives in a personal account, do not accept a verbal promise. Put specific handover tasks into the deal. A holdback works well when the problem is serious but fixable.

Keep those tasks concrete. Ask for a new admin account in source control, cloud, domains, app stores, monitoring, backups, and email systems. Ask your team to run one real deployment before money fully clears. If they cannot ship a small change safely, you still do not control the product.

After closing, the first 30 days need a short plan, not a giant cleanup project. Decide who owns support, who watches alerts, who can roll back a bad release, and where secrets and billing access will live. A small SaaS does not need perfect process on day one, but it does need one release path that your team can run without asking the former builder for help.

A small example makes this easier to judge. If the app runs fine but the seller never moved the domain, payment gateway, and server billing out of personal accounts, that is not a minor admin task. It can block support, renewals, and emergency fixes. Push those transfers forward before closing, or hold back enough money to make sure they happen.

If the picture still feels unclear, a focused outside review can help. Oleg Sotnikov at oleg.is does this kind of narrow continuity, ownership, and deployment review for startups and small businesses, which is often enough to surface the real handover risk before you sign.