How to Audit a Website or Digital Product Before You Buy It

Buying a website, SaaS product, e-commerce business, marketplace, or other digital product is rarely a matter of looking at revenue and checking whether the interface looks good.

You are not buying a website. You are buying a system whose problems become yours the moment the transaction closes.

A digital product can have impressive traffic and healthy-looking revenue while being held together by outdated code, fragile integrations, undocumented infrastructure, poor search visibility in the wrong market, or a business model that depends entirely on one person who is about to leave. The opposite is also true. A product with an outdated interface may contain valuable technology, strong organic visibility, a loyal customer base, or an architecture that can be modernized without rebuilding the business from zero.

We saw the expensive version of this firsthand with a client who bought an existing e-commerce business specifically to revive it. The purchase price included the site itself and its search rankings, and those rankings genuinely were strong, just entirely in Russian, at a moment when Ukrainian-language search was already becoming the more important market.

The rankings were real. The technology was real. The revenue was real. The problem was that none of those things meant what the buyer thought they meant.

Underneath the interface sat ancient PHP with a pile of custom, self-written modules, no documentation, and an implicit "figure it out yourself" left behind by whoever built it. This was 2019, before AI tools could meaningfully help analyze or untangle a legacy codebase like that; there simply wasn't a shortcut available yet.

The site eventually had to be rebuilt entirely from scratch. Product data had to be re-parsed and refilled because SKU records were riddled with errors. The business ran on an old Russian 1C installation that obviously needed replacing. No audit had been done before the purchase, and the overpayment --- for the site and for search positions that didn't match where the market was actually heading --- was enormous. In the end, the work had to be done again anyway.

Before you buy a digital product, don't ask whether you like it. Ask whether you understand it.

START WITH BUSINESS

Start With the Business, Not the Code

The first mistake buyers make is opening the website. The second is opening the source code. Neither should be the first step.

Before examining implementation details, establish what the digital product is supposed to do as a business: where revenue actually comes from, who the customers are, how they're acquired, how dependent the business is on one customer, channel, employee, supplier, or platform, and which parts of the operation are automated versus still held together by manual work.

A website with \$500,000 in annual revenue isn't automatically worth more than one with \$300,000. If the first depends on a single advertising platform, one employee, and a proprietary integration nobody else understands, while the second has diversified acquisition, documented processes, and a stable technical foundation, the underlying risk profile is completely different.

The audit begins with a simple question: what exactly generates the value? Only after that question is answered does it make sense to ask whether the technology actually supports it.

REVENUE TRAFFIC SIGNALS

What Generates the Value: Revenue and Traffic as Signals

Revenue should be broken down, not presented as one impressive number.

For e-commerce, that means separating gross from net sales, average order value, conversion and repeat purchase rates, and revenue by product, channel, and geography. For SaaS, it means recurring revenue, churn, expansion revenue, and how concentrated revenue is across accounts. For lead generation, it means cost per lead, lead-to-sale conversion, and where the leads actually come from.

The purpose isn't only to verify the seller's numbers. It's to understand how the product actually makes money. A website can have millions of visitors and almost no economic value, and another can have modest traffic that generates highly valuable leads for a specialized niche. Traffic is an asset only when it connects to an economic outcome, and that connection needs verifying, not assuming.

The same discipline applies to traffic itself. A site showing 200,000 monthly visitors today looks completely different depending on whether that traffic grew steadily over three years or dropped from 500,000 six months ago.

For SEO-driven businesses, it is worth knowing how much of the business depends on a small number of pages. If 70% of organic traffic comes from ten URLs, the business is considerably more fragile than the headline number suggests, and a single algorithm change or migration mistake can matter enormously.

TECH STACK MAINTAINABLE

The Technology Stack and Whether the Code Is Actually Maintainable

Only after the business is understood does it make sense to open the technical architecture. The goal is a complete dependency map: languages, frameworks, database, hosting, APIs, payment systems, third-party libraries, scheduled jobs --- everything the product actually depends on to function.

A seemingly simple e-commerce site might genuinely depend on a chain running from frontend through an API, an application layer, a database, a payment provider, an ERP, inventory and shipping systems, email, analytics, and a third-party search service. If any single link in that chain is poorly documented or unsupported, the acquisition inherits that risk directly.

This is exactly the wall the 2019 e-commerce acquisition ran into. The custom PHP modules had no documentation and no departing explanation beyond an implicit expectation that someone would eventually figure it out.

Today, AI-assisted code analysis can meaningfully shorten that discovery process. It can help a technical reviewer understand what a legacy system actually does faster than manual tracing alone. It still can't replace a real audit, and it doesn't turn undocumented code into documented code, but the floor for what's discoverable before a purchase is considerably higher now than it was then.

A codebase does not have to be beautiful. It has to survive the person who wrote it leaving the room.

The real question worth asking is whether a competent developer could take over the system on their own. If the honest answer is no, the buyer isn't acquiring a self-contained digital product. They're acquiring a dependency on a specific person, and that dependency has a real price.

INFRASTRUCTURE SECURITY

Infrastructure, Deployment, and Security

A digital product is not just its source code. It's where that code actually runs and how changes actually reach production.

That means reviewing hosting, environments, backups, disaster recovery, DNS, monitoring, and the deployment process itself, and asking someone to walk through that process end to end.

"We usually SSH into the server and change it manually" describes a materially different operational risk than a documented CI/CD pipeline with rollback capability, even when both technically work today.

It's also worth confirming who actually owns the infrastructure. It's surprisingly common for critical assets to sit inside an employee's personal account, a developer's cloud account, or an agency's hosting environment rather than the business's own.

Security deserves the same scrutiny, since the acquisition includes customer accounts, payment-related information, proprietary business data, and credentials, not just code.

Two questions are worth asking directly and specifically: has the product ever been hacked or compromised, and who currently has production access?

That second question gets overlooked more often than it should. A business can have genuinely strong security controls and still have a handful of former contractors holding active server credentials nobody remembered to revoke.

DATABASE AND DATA

The Database and the Data

For many digital businesses, the database is one of the most valuable assets, and its value depends entirely on its quality.

The 2019 acquisition made this concrete in an expensive way. Product records were riddled with SKU errors and inconsistencies accumulated over years of ad-hoc changes, and the buyer ended up re-parsing and refilling the product catalog essentially from scratch --- work that should have been priced into the original deal rather than discovered afterward.

Structural problems tend to compound quietly. If customer information exists across several independent systems with inconsistent identifiers, migration becomes expensive in ways that are hard to estimate upfront.

If product data depends heavily on custom fields accumulated over years, moving to a new platform can require significant reconstruction rather than a straightforward export. And if analytics can't be reconciled with transaction data, the business may struggle to even prove its own historical performance convincingly.

Data is both an asset and a liability, and which one it turns out to be usually isn't visible from the outside.

SEO FRAGILE ASSET

Content and SEO as a Fragile Asset

If the acquisition includes a content-heavy site, page count alone means almost nothing.

Ten thousand indexed pages with strong internal linking and real organic demand are an asset. Ten thousand automatically generated, thin pages are technical debt wearing the shape of an asset.

SEO deserves its own scrutiny for the same reason: organic visibility can be one of the most valuable and most fragile things included in a digital acquisition, and the real question is why the site ranks at all.

A strong brand, a large backlink profile, genuinely useful content, weak competition in the niche, or a temporary search trend can all produce similar-looking traffic charts and completely different levels of durability going forward.

The 2019 case is the clearest possible illustration of this. The seller's asking price explicitly included strong search rankings, and those rankings were real, just concentrated almost entirely in Russian-language search, at the exact moment the market was shifting toward Ukrainian-language demand becoming more commercially important, the same discipline covered from the build side in multilingual AEO.

The rankings were a genuine asset in one market and close to irrelevant in the one the business actually needed to compete in going forward.

Visibility that doesn't match where demand is actually moving isn't really the asset it appears to be on paper. This is exactly the kind of gap a real audit is supposed to surface before the purchase, not after it.

UX AND PERFORMANCE

UX, Conversion, and Performance

A digital product can technically function perfectly and still be commercially inefficient.

Walking the actual customer journey --- landing page to category to product to cart to checkout for e-commerce, or landing page to registration to activation to retention for SaaS --- surfaces where users leave, where friction is unnecessary, and where the experience breaks down across devices.

Analytics shows that something is happening. A usability review helps explain what.

Performance deserves the same honesty. A site can feel fast to its owner because their own browser has already cached most of it, while a first-time mobile visitor experiences something completely different. That gap has real financial consequences for conversion, advertising efficiency, and search visibility alike.

The useful question was never simply "is the website fast?" It's whether there's a meaningful performance problem, and what it would actually cost to fix.

THIRD-PARTY DEPS

Third-Party Dependencies

This is one of the most consequential parts of a digital acquisition, and one of the easiest to underestimate.

For every external service the product depends on, it's worth knowing who owns the account, who pays for it, whether the contract actually transfers, and whether the account can move to a new owner at all.

The old Russian 1C installation underneath the 2019 acquisition was exactly this kind of dependency: a system that clearly needed replacing, tied to infrastructure and licensing the new owner had no real path to simply inherit.

A \$500-a-month external API is a manageable cost. The same API tied to the seller's personal agency account, with no transferable contract, turns an identical technical setup into a completely different financial and operational problem the moment ownership changes hands.

INTELLECTUAL PROPERTY

Intellectual Property

Ownership is frequently more complicated than buyers expect.

Source code, designs, photography, copy, trademarks, domains, and proprietary algorithms all need a clear, verifiable owner, not an assumed one.

If an agency built the product, it's worth directly confirming the seller actually owns the resulting code rather than merely having a license to use it. If freelancers contributed along the way, intellectual-property assignment documents should exist and should be checked, not taken on faith.

A buyer shouldn't discover after closing that the "proprietary platform" quietly contains code the seller was never actually entitled to sell.

PEOPLE AND KNOWLEDGE

People and Knowledge: What Happens When One Person Leaves

Some digital products are genuine software businesses. Others are software-shaped businesses that are actually operated manually behind the scenes by one or two people who happen to know where everything lives.

We've seen this pattern surface in a due diligence context in almost the same shape as the broader problem of enterprise systems that started as someone's spreadsheet, except here the stakes were an acquisition, not an internal process.

The business's real operational logic lived inside one person's spreadsheet --- an enormous, genuinely impressive web of interlinked relationships across thousands of rows. It worked, right up until access to that person's understanding of it became uncertain, at which point the practical usefulness of all that accumulated data collapsed to almost nothing.

Nobody else could reconstruct the relationships fast enough to matter.

The question worth asking directly is simple: what happens if this person disappears tomorrow?

A genuinely good acquisition comes with enough documentation and knowledge transfer that the buyer can gradually replace individual dependencies on their own timeline, not be held hostage to one person's continued availability and goodwill.

REAL COST OWNERSHIP

The Real Cost of Ownership and Rebuilding

Revenue shows what comes in. The audit has to establish what actually goes out: hosting, subscriptions, APIs, development, maintenance, support, advertising --- separated into essential costs versus optional ones.

A seller reporting \$8,000 a month in operating costs might mean \$3,000 of that is an unrelated personal expense and \$4,000 is a contractor who happens to be the only person who knows how to keep the platform running.

The number that actually matters isn't historical spending. It's the realistic future cost of operating the product after the acquisition closes.

A related, genuinely useful exercise asks three separate questions rather than one: what it would cost to rebuild the product today at replacement cost, what it would cost to modernize the existing product specifically, and what it would cost to fix the critical risks identified during the audit.

A product might have \$200,000 of genuinely useful technology and still require \$80,000 of immediate work. That doesn't mean the product is worth \$120,000, but the buyer absolutely needs to understand that required investment before agreeing to a price, not after, exactly the same discipline covered more broadly in the build vs. buy equation.

RISK MAP NOT REPORT

The Audit Should Produce a Risk Map, Not a Report Nobody Reads

A forty-page technical report nobody actually reads isn't a useful outcome. The findings need translating into business consequences, in a form specific enough to negotiate against.

Sample Risk Map

The purpose was never to produce a score. It's to make the unknowns visible, in writing, before they become the buyer's problem instead of the negotiation's.

Technical debt discovered before the purchase is a negotiating point. The same debt discovered after closing is simply a cost.

WHAT YOU'RE BUYING

What You're Really Buying

A digital acquisition should ultimately be evaluated as one system, not a checklist of separate parts.

The website is one component. The code, the database, the SEO, the customers, the infrastructure, the integrations, the content, the processes, and the intellectual property all contribute to what's actually being purchased.

A useful, deliberately informal way to hold that together is: value roughly equals business performance plus digital assets plus technology plus data plus growth potential, minus technical debt, minus operational dependency, minus hidden liabilities.

It isn't a literal formula. It's a reminder that the purchase price should never be set by the visible interface alone, the same architectural thinking covered more broadly in what you own vs what you're renting, applied specifically to the moment ownership is about to change hands.

A beautiful website can conceal a weak business. A dated one can conceal a genuinely valuable digital asset. And a technically impressive product can still be a poor acquisition if nobody actually knows how to operate it without its original creator standing beside them.

The purpose of an audit was never to decide whether a product is good or bad.

It's to replace assumptions with evidence: what works, what doesn't, what depends on one person, what's genuinely transferable, and what risk the buyer is actually accepting on the day ownership changes.

How is a digital acquisition audit different from a standard technical audit?

A technical audit usually asks whether the code is good. An acquisition audit asks something broader: whether the business, the data, the SEO, the infrastructure, and the people dependencies can all actually transfer to a new owner without quietly falling apart in the process.

How long does a proper digital product audit typically take?

It depends heavily on the size and complexity of the product, but a meaningful audit covering business, technical, data, and legal dimensions typically takes several weeks, not days. Rushing it tends to produce exactly the kind of expensive surprise this article describes.

Is it possible to do this audit ourselves, or do we need outside help?

Some of it, yes, particularly the business-model questions in the early stages. The technical, security, and data dimensions usually benefit from an outside technical reviewer who has no incentive to accept the seller's framing and can independently verify what the code, infrastructure, and data actually do.

What's the single biggest mistake buyers make in a digital acquisition?

Treating the interface as a proxy for the whole business. A polished storefront and strong-looking traffic numbers can sit directly on top of undocumented code, fragile third-party dependencies, or search rankings that don't match where the market is actually heading, and none of that becomes visible without a real audit.

Does AI make this kind of audit faster or less necessary today?

Faster in places, not less necessary. AI-assisted code review can meaningfully speed up understanding a legacy codebase, something that simply wasn't available even a few years ago. It doesn't replace verifying ownership, checking real infrastructure access, or confirming that data and rankings actually transfer to a new owner.