What a well-built product looks like to a reviewer

A technical review is built to find problems, so most reports read like a list of what is wrong. That is useful, but it leaves a gap. A buyer who sees only the problems cannot tell a sound product with ordinary gaps from a fragile one with the same number of findings. Both reports are long. Only one describes a system the buyer can safely build on.

Sellers feel the same gap from the other side. Founders of well-run products often say the code is clean, the team is strong and the platform scales. To a reviewer those are impressions, and impressions carry no weight in a report. What carries weight is evidence: something a reviewer saw in the systems, can point to, and would expect another reviewer to see as well.

This note is the reviewer's view of what a well-built product looks like, how each sign is checked, and why strengths have a place in the report next to the findings.

Why strengths belong in the report

Our report has a layer-by-layer section that sets out what we saw in each of the six layers, the strengths as well as the problems. That section is not there to soften the findings. It is there because a deal team needs the whole picture to read the findings correctly.

Three reasons matter most in practice:

• Context for severity. A missing test suite around one module means something different in a product with a reliable pipeline, good monitoring and a team that knows the code than in one with none of those. The strengths explain why a finding is rated Medium rather than High on our severity scale.
• Cost estimates depend on them. Every cost to fix assumes a starting point. If the product has automated deployment and tests on the paths that carry money, fixes are cheaper and safer to make. A report that hides those facts makes its own estimates harder to check.
• The plan after closing builds on them. The 100-day plan should use what already works, not rebuild it. Knowing that infrastructure is defined in code, or that error tracking already covers production, changes what the new owner needs to fund.

Strengths never offset findings. A tidy codebase does not cancel a cloud account held by a former contractor. Each finding stands on its own, and the strengths sit beside it as facts, not as credits in a ledger. Whether any of it moves price or terms is a matter for the deal team and its counsel, not for the reviewer.

Built to last means cheap to change

A product that is well built and one that merely works can look the same in a demo. The difference appears when someone asks the system to change: a new integration, a second market, a pricing model, a larger customer, a new owner's plan. A buyer pays for a product that will be asked to change after closing, so this is the property a reviewer is really testing.

Our engineering partner PERETZ looks at the same question from the build side, with two common PHP frameworks as the example, in What Separates a Premium Laravel or Symfony Build From a Merely Functional One. Its point holds for a reviewer as well: the framework is rarely the reason one product ages better than another. The decisions made inside it are.

That is why this note is framework-neutral. The same signs apply to a Rails monolith, a Node.js service fleet, a Django product, a .NET system or a mobile app with a backend. The tools differ. The evidence a reviewer looks for is the same: whether the system can be understood, changed, released, watched and handed over without depending on luck or one person's memory.

Nine signals and the evidence behind them

These are the signals we look for across the six layers. None is proof on its own. Together they describe a system built to last. The table sets out what a reviewer looks at and what kind of evidence settles the question.

Structure, tests and deployment

These three decide how safely the product can change. A reviewer does not grade style. The question is whether an engineer new to the code can find where a rule lives, change it, know whether something else broke, and put the change into production without ceremony. The commit history is a useful check: when an ordinary feature touches a handful of files in one area, structure is doing its job. When every change spreads across the codebase, it is not.

Coverage figures are weak evidence. A high percentage built from tests that check nothing important says less than a smaller suite that covers pricing, permissions and payments with real assertions. We read the tests, not the badge.

Observability and documented decisions

These decide how well the system can be run and handed over. A product that reports its own errors, failed jobs and slowdowns lets a new owner operate it from evidence rather than from customer complaints. Written decisions do the same for knowledge: they keep the reasons behind the code when the people who made them move on, which is why they weigh heavily in the team layer and in any reading of key-person risk.

Dependencies, data and security

These decide what the buyer inherits. Supported versions mean security fixes keep arriving. A careful data model means reporting, migration and integration after closing rest on data that means what it says. Basic security, done consistently, is where most real exposure sits, and it is also what insurers and enterprise customers ask about first.

A team that can explain its trade-offs

This is the signal people underrate. Every product has compromises. A team that can name them, explain why they were made and say what they would cost to undo is showing that it understands its own system. When the engineers' account matches what the reviewer finds in the code, the rest of what they say becomes easier to trust. When it does not, every other answer needs checking.

Impressions that do not count as evidence

Many things that feel like strengths in a meeting do not survive a review. A reviewer notes them politely and moves on to the systems.

• A smooth demo. It shows the product works with demo data and a presenter who knows the path. It says nothing about change, scale or recovery.
• A popular framework. A good choice of tools is a starting point. Well-known frameworks can host fragile code as easily as careful code.
• Architecture diagrams. Useful when they match the system. A diagram that shows services the repository does not contain becomes a finding, not a strength.
• Coverage percentages and quality badges. They count lines, not whether the important behavior is checked.
• "We follow best practices." Every team says it. The pipeline configuration, the release history and the access list say whether it is true.
• A long policy folder. Security and backup policies matter only when the systems show they are followed. A backup policy with no restore test is a policy, not a backup.

The rule we apply to strengths is the same one we apply to findings: we write down what a person on our team has seen, where it was seen, and whether it came from the systems or from an interview. Our note on technology claims in a sale document covers what happens when the seller's own words and the evidence disagree.

How a strength is written up

A strength in our report follows the shape of a finding, without a cost to fix. It states a fact, names the layer, gives the evidence with a reference, and says what it means for the buyer's plan. Like a finding, it should be specific enough for the other side to check. A generic, fictional illustration:

Releases are automated, frequent and reversible. Layer: Code & architecture. Evidence: pipeline configuration in the repository (read-only access); release history for the last twelve months shows weekly releases by four different engineers; two rollbacks in that period, each completed through the pipeline in minutes; staging step required before production. Meaning for the plan: changes in the first 100 days can go out in small steps with a known way back; cost estimates for other findings assume this pipeline stays in use. Limits: no automated checks on database migrations; covered as a separate Low finding.

Two details matter. First, the strength carries its own limits, so it cannot be quoted as broader than it is. Second, it is tied to the plan. A strength that matters for a buyer who will scale the product may matter less for one who will merge it into its own platform, and the report says which plan it was read against.

Strengths are verified with the same care as findings, under the same access protocol: read-only accounts, no copies of personal data, everything we received listed in the report. Checking that a strength is real takes as long as checking that a problem is real. It is not a shortcut through the review.

Making strengths visible in the data room

A well-built product does not show itself. If the data room holds only contracts, a short architecture overview and a statement that the code is maintainable, a reviewer has to rebuild the evidence from scratch, and the strengths may be found late or described in less detail than they deserve. A seller can do much of that work in advance, without overstating anything.

• Point to the systems, not to adjectives. Instead of "mature CI/CD", give the reviewer read access to the pipeline and a summary of release history: how often, by how many people, how many rollbacks.
• Show the tests where money moves. List which flows are covered by automated tests and where those tests live. Be plain about the areas that are not covered.
• Export the monitoring picture. A short note on what is watched, who is alerted and the last few incidents, with how each was found and closed.
• Date the documents. Architecture notes, runbooks and decision records with dates and owners read as current. Undated documents read as old.
• Include the dependency and license scans. With support dates and a plan for anything near its end of life.
• Let the team speak for itself. Make engineers beyond the lead available for interviews, and include the team's own list of what it would fix first. A known weakness with a plan reads better than one the buyer finds alone.

The structure of that part of the data room, and the order a reviewer reads it in, is covered in the technical section of the data room. The aim is consistency: the documents and the systems should tell the same story, so a strength described in the room is a strength the reviewer confirms.

A checklist of a product built to last

Questions a seller can ask before going to market, and a buyer can ask of any technical report:

• Can an engineer new to the code find where a given business rule lives within a short time?
• Do automated tests cover billing, permissions and the main integrations, and do they run on every change?
• Can more than one person deploy, and has a rollback been done through the normal process?
• Are production errors and failed jobs reported to a named person before customers notice?
• Are architecture notes and runbooks dated, owned and close to the code they describe?
• Are the framework, runtime and main dependencies on supported versions, with a license scan on file?
• Do database migrations apply cleanly in order, and do constraints protect the data that matters?
• Is the repository history free of secrets, is MFA on every critical tool, and were leavers removed on time?
• Can several engineers describe the same weak spots, and do those match what the code shows?
• Does the report state each strength with evidence and limits, and say which plan it was read against?

What to do next

If you are buying, ask for a report that shows the strengths as well as the findings, with evidence for both, and share your plan for the product with the reviewer, because it decides which strengths and which problems matter. Our technical due diligence reports that way, at a fixed fee agreed in writing before we start. How findings are priced alongside those strengths is covered in how technical debt is measured and put into a deal.

If you are selling a product you believe is well built, the work is to make that belief checkable. Vendor due diligence gives buyers an independent reading of the strengths and the findings from one review. With more time before a sale, exit readiness turns the signals in this note into evidence month by month. Neither is quick, and neither replaces the buyer's own review. Both put the facts in front of the people who decide.

Questions