Due diligence prep for an agency-built product sale

Why agency work creates diligence gaps

Agency projects often move fast. That speed helps a startup ship, but it rarely leaves a clean record of who owns what.

The agency wants to launch. The founder wants the product live. Few people stop to ask who owns every file, who controls every account, or who can prove it six months later.

That becomes a problem when a buyer starts asking for proof that the company owns the product. If the source code sits in the agency's GitHub account, the design files live under a freelancer's login, or the cloud environment was opened with someone else's email, ownership looks blurry even if every invoice was paid.

This is why diligence gets messy so often after agency work. A contract may cover delivery but not a full IP assignment. A developer may have used paid plugins, stock assets, or third-party tools under licenses that do not transfer with a sale. The company may have the app, but not clear rights to every part inside it.

Missing records turn basic questions into delays. A buyer asks, "Who owns the backend code?" and now the team is digging through old statements of work, email threads, Slack exports, and handoff notes. A question that should take five minutes can eat a week.

Small gaps also create bigger doubt. If you cannot show clean ownership, buyers start asking what else is undocumented: vendor access, security practices, deployment steps, or even who can keep the product running after the deal closes.

A simple example makes the risk obvious. A startup paid an agency to build its app, then learned that the production server, app store account, and analytics tools were still under agency control. The product worked. The handoff did not.

What buyers ask for first

Buyers usually start with control, not features. They want to know where the live code sits, who owns the work the agency produced, which paid services keep the product running, and how a release reaches production. If you cannot answer those points quickly, the deal slows down.

The code repository is often the first pressure point. A buyer will ask where the live code sits today, who has admin access, and whether your company can move or back it up without the agency. If the product still lives in the agency's GitHub or GitLab space, expect questions right away.

They also want signed contracts that clearly assign intellectual property to your company. An invoice does not solve that on its own. Buyers look for the master services agreement, statements of work, and any assignment language that covers code, designs, and custom integrations.

The first package does not need to be fancy. It just needs to be clear. A buyer should be able to see the main repo location and current admins, the signed agency contracts and IP terms, the list of tools and paid accounts tied to the product, and plain notes that explain how code moves from the repo to production.

The account list matters more than many founders expect. Buyers will check hosting, domains, app store access, email, analytics, error tracking, and third-party APIs. If billing still runs through the agency, the obvious question is whether the business can operate on its own after closing.

Deployment notes can stay simple. A buyer just needs a clear path. Which branch ships? Who approves a release? Where do secrets live? What breaks if one account gets locked?

If you can hand over those basics in one folder on day one, buyers spend less time chasing missing facts and more time looking at the business.

Make an ownership map

Buyers want one plain document that shows who controls every asset tied to the product today. When a company used an agency, that control often sits in five different places, and nobody notices until a buyer asks for access.

A spreadsheet is enough. In practice, this ownership map saves more time than most pitch decks. Create one row per asset, then add columns for current owner, who has login access, where it lives, and whether you have written proof that your company owns it.

Start with the assets buyers care about most: source code and deployment configs, designs and brand files, domains and DNS, databases and backups, cloud accounts and analytics, app store listings, payment accounts, and vendor dashboards.

Write the actual owner next to each item, not the owner you assumed you had. If the GitHub organization belongs to the agency founder, say that. If the AWS account sits under a contractor email, mark it. If the iOS app ships from the agency's Apple Developer account, flag it immediately.

Then add a simple risk label. "Company owns it," "shared control," "agency controls it," or "proof missing" is enough. That last label matters. Paid invoices do not prove IP ownership by themselves, and verbal promises do not help when a buyer's lawyer starts checking details.

A startup may own the code in practice while the agency still controls the production server, the domain registrar, and the Play Store listing. That alone can slow a deal.

When the map is done, you should be able to see every weak spot on one page. That gives you a clean order for the fixes that come next.

Pull together the paper trail

Paperwork decides whether diligence feels calm or chaotic. If an agency built the product, the proof of ownership usually sits in old inboxes, shared drives, and billing threads.

Start with the full contract chain, not just the main agreement. You need the master services agreement, every statement of work, each change request, and every signed amendment. One missing document can break the story of who built what and under which terms.

Then read the language carefully. Check that the contract assigns IP to your company and covers code, designs, documentation, build scripts, and other deliverables. Also check who owned work from subcontractors. Many agencies use freelancers, and if the contract does not pull that work into the same assignment, a buyer may ask uncomfortable questions.

A short note beside each document helps. Record the date, the parties, the project name, and where the IP language appears. That saves time later when someone asks for proof during a deal call.

Keep the supporting evidence with the contracts. That includes invoices and proof of payment, acceptance emails for milestones or final delivery, handoff messages for code or credentials, meeting notes that confirm scope changes, and exports from project tools if they show approvals.

These records matter because they show a full chain: the work was ordered, delivered, and accepted. If an agency says, "we transferred everything," the email and invoice trail makes that claim real.

Store clean copies in one folder with simple file names such as "2023-04-12_MSA_AgencyName_signed.pdf" or "2023-07-03_SOW_2_backend_changes.pdf." Keep the signed version, and keep a readable copy if the scan is messy.

Do not leave this as a pile of screenshots and forwarded emails. Merge loose items into PDFs, remove duplicate drafts, and mark the final version clearly. When a buyer asks who owns the app, you want one folder that answers the question in two minutes.

Review licenses and vendor accounts

A product can look fully owned on paper and still contain parts you cannot legally keep using. That happens a lot after agency work, and buyers find it quickly.

Start with one inventory that covers the whole product, not just the codebase. Review the app, design files, deployment setup, marketing assets, and every third-party service the product depends on. Another person should be able to read the record in ten minutes and understand what is safe, what is risky, and what needs replacement.

For each item, note the name, where the product uses it, the license or subscription terms, who bought it, whether your company can keep using it after handoff or sale, and what you will replace if the answer is no.

Include open-source packages, paid libraries, fonts, stock images, icon sets, plugins, templates, and hosted tools. Then check the actual terms. MIT and Apache usually create fewer issues than GPL or commercial licenses, but do not guess. Read the license and note any obligations such as attribution, source disclosure, seat limits, or resale limits.

Agency-owned subscriptions create a different problem. An agency may have used its own cloud account, font plan, design plugin, monitoring tool, map service, or email provider while building your product. If your product still depends on that account, you do not fully control billing, admin access, exports, or service history.

Fix anything your company cannot legally keep using before a buyer asks. Replace the asset, move the account into your company, or buy a fresh license in your own name. If the agency used a paid font under its own design subscription, swap it out or license it directly. That is a cheap fix now and an annoying delay later.

Write down how the product goes live

A buyer gets nervous quickly when only the agency knows how to push code, restart services, or find logs. You want one simple document that shows how a change moves from a developer's commit to the live product, and who controls each step.

Start by naming every environment clearly. Most teams have development, staging, and production, but agency work often leaves extras behind, such as a demo server, a test cloud account, or a second production box used for hotfixes. If an environment still exists, list it and explain what it does.

At a minimum, your deployment note should identify the code repositories, the branch used for releases, the cloud services and databases the app depends on, where secrets live, and the CI jobs, build scripts, and monitoring tools used after release.

Then write the release path in plain language. Skip jargon. A buyer should understand it even if they have never seen your stack before. For example: a developer merges code into the main branch, the CI job runs tests, the build creates a container image, the deploy job pushes it to staging, someone checks staging, and an approved person deploys the same version to production.

Be specific about access. Name who can deploy, who can approve a release, who can roll back, and who can reach logs and alerts when something breaks. If the agency still holds any admin account, say so. It is a fixable issue, but buyers will flag it.

A short rollback note helps too. If a release fails at 6 p.m., who gets called, where do they look first, and how do they restore the last working version? Even half a page can save days of buyer questions and show that the product can run without guesswork.

Fix the gaps in a sensible order

Start with anything that affects ownership. If the company cannot prove who owns the code, designs, domain, and data, neat folders will not help much. Buyers usually forgive messy formatting. They do not forgive missing assignment terms, unclear contractor status, or code that may still belong to an agency or freelancer.

After that, move accounts back under company control one at a time. Do not try to switch everything in one afternoon. Transfer the domain registrar, cloud account, source control, app store accounts, analytics, email, and payment tools in a clear sequence. Each time an account changes hands, record who owns it now, who still has access, and what still depends on it.

Agency access can disappear fast, sometimes right after a contract ends. Before that happens, export what you can from their tools. Save build logs, deployment settings, environment variable lists, DNS records, design files, backups, invoices, and change history. A basic export today can save days of guesswork later.

A simple order works well:

1. Confirm ownership and signing authority.
2. Secure admin access to core accounts.
3. Export records from agency-managed tools.
4. Recreate missing deployment and recovery notes.
5. Put everything in one shared folder.

Give one person the job of tracking the cleanup. That person should keep the open-item list, assign due dates, and chase missing documents. Without a single owner, gaps tend to sit for weeks because everyone assumes somebody else already asked the agency.

Mistakes that slow a deal

Buyers rarely get stuck on the fact that an agency built the first version. They slow down when the company cannot prove control. That turns a simple review into legal back-and-forth, extra calls, and price pressure.

One common mistake is treating paid invoices as proof of ownership. An invoice shows that money changed hands. It does not automatically transfer copyright, source code rights, design files, contractor work, or rights to reuse third-party components. If the contract does not say the company owns the work, buyer counsel will ask for assignments, amendments, or fresh signatures.

Another delay shows up in deployment. Often one agency engineer knows the production server, build steps, secrets, and rollback process from memory. If that person is gone, nobody can explain how a release reaches customers. Buyers read that as operational risk, even if the app runs fine today.

Access gaps are often the most awkward part. A team may control the code repo but forget the domain registrar, DNS, email sender, analytics account, Apple App Store, Google Play Console, or cloud billing owner. Those accounts matter because they control distribution, resets, invoices, and sometimes the brand itself. If they sit under an agency email or a former founder's login, the buyer will stop and ask who can actually hand them over.

Billing trails can look just as messy. Personal cards, agency billing, and company subscriptions often get mixed during the early startup phase. Later, nobody knows which services belong to the company and which depend on a private account. That creates risk around continuity and transfer costs.

A simple test helps. Pick one feature release and trace every step from code to customer. Name the repo owner, cloud account, registrar, package owners, app store account, and payment method. If any answer starts with "I think" or "the agency handled that," fix it before a buyer asks.

Quick buyer-ready checklist

You do not need a perfect data room. You need clear proof that your company owns the product and can keep it running after the agency steps away.

• Contracts and statements of work should clearly assign code, designs, docs, and other deliverables to your company.
• Your team should hold admin access to repos, cloud hosting, DNS, app stores, analytics, email, and payment tools.
• The license record should match the product that actually runs in production.
• Someone on your team should be able to deploy the product and roll it back without agency help.
• One folder should hold the paper trail, account list, deployment notes, and a plain-language system summary.

One missing item will not always kill a deal. A few small gaps together often slow legal review, lower buyer confidence, and create room for holdbacks or extra warranty terms.

If you can answer each point in a few minutes and pull up the supporting files immediately, the diligence process feels much cleaner.

Example: a startup with missing handoff docs

A small SaaS company spent its first year moving fast. The founder hired one agency to handle most of the work: product development, design, and the initial cloud setup. It felt tidy at the time. One team built the app, shipped updates, and kept the servers running.

That setup looked fine until a buyer started diligence. The buyer asked three plain questions: who owns the code repository, who controls the AWS account, and who has the original design files? The founder had verbal answers, but not paper proof. The agency had created the repo under its own workspace, opened the cloud account with an agency email, and stored design files in its internal tool.

Nothing was broken, but nothing was clean either. That is what slows deals down. Buyers do not like guessing who could lock them out after closing.

The founder fixed it in a week, but only because the agency cooperated. Both sides signed short addendums that made ownership clear for code, designs, and deployment scripts. Then the founder moved account access into company-owned email addresses and admin seats. The repo changed hands. The AWS root account and billing access moved too. The design files went into a workspace the company controlled.

One small document made the biggest difference. The founder wrote a two-page deployment note in plain English. It explained which repo went to production, who could deploy, which cloud services were in use, where environment variables lived, and what would break if a subscription expired.

That note stopped weeks of back-and-forth because the buyer no longer had to pull answers out one by one. The usual order holds up well: ownership first, access second, deployment path third. Once those three are clear, the rest gets much easier.

Next steps before buyer outreach

Start with a simple split: what can you fix this week, and what needs a proper cleanup plan. Buyers do not expect perfection, but they do expect you to know where the gaps are. A missing signature page, an ex-contractor still owning a repo, or unclear cloud access can turn a normal review into a trust problem.

This first pass should cover the items that change risk fastest. Collect signed IP assignments and contractor agreements. Confirm who controls source code, domains, cloud accounts, and app store accounts. Write a short deployment note that shows how the product goes live. List the third-party tools, paid services, and licenses that need review.

Then put slower work on a second track. That usually means cleaning old repos, moving shared vendor accounts into company ownership, and replacing licenses that do not allow resale or commercial use. If you cannot finish those before outreach, document the issue, the impact, and the target fix date.

A mock diligence review helps more than most founders think. Ask someone who did not build the product to request the basics: ownership documents, access lists, vendor contracts, deployment notes, and a simple architecture summary. If that person gets confused in 20 minutes, a buyer probably will too.

Keep the package alive after you build it. Set one owner, keep one folder structure, and update it when you change vendors, move infrastructure, or add contractors. Rebuilding everything under deadline usually creates mistakes, and buyers notice sloppy records.

If the handoff still feels messy, get an outside review before buyer calls start. Oleg Sotnikov at oleg.is works as a Fractional CTO and startup advisor, and this kind of ownership, infrastructure, and deployment cleanup is much easier to fix early than defend later.