You can check the work without reading the code

The uncomfortable position in a software purchase is being asked to judge work you cannot read, by people whose confidence is not evidence. The usual responses are to hire a technical advisor, to rely on references, or to pick on rapport and hope.

There is a better option, and it does not require you to become technical. Ask for four artifacts. Each has a plain-language answer, each takes a competent firm under a day, and the refusals tell you as much as the deliveries.

1. A build somebody else can run¶

Ask them to check out the project on a machine that has never built it and produce a running copy, with the instructions they followed. Not a demo of the software, but the act of building it from source on clean hardware.

This is the most informative single request available to a non-technical buyer, because it is pass or fail and it cannot be argued with. A project that only builds on the laptop of the person who wrote it is a project you cannot take anywhere, cannot hand to anyone, and cannot get a second opinion on. It is also, quietly, the most common defect in inherited codebases.

Good answers take an afternoon and produce a page of instructions. Bad answers explain why this is unusual, or involve one specific person.

2. A test run, with its output¶

Ask to see the automated tests run, and ask for the output. You are not going to read the tests. You are looking for three things you can see without reading anything: that there are some, that they pass, and that running them takes minutes rather than being something people do occasionally.

Then ask the question that matters more than any coverage number: name a business rule that would be expensive to get wrong (an order cannot ship before payment clears, a user cannot see another region’s records) and ask which test fails if somebody breaks it. Then ask to watch it fail. A test suite nobody has ever seen go red is a suite that has not been shown to check anything.

3. A dependency and license report¶

Every modern system is mostly other people’s code. Ask for the list, with each item’s version, how far behind current it is, and its license. The tooling to produce this ships with the language; nobody is writing it by hand.

It answers two questions at once. What is stale, which is a maintenance cost you are about to inherit and a security exposure you are about to own. And what you have taken on legally, because a dependency under a strong copyleft license in a product you intend to sell is a conversation your lawyers would rather have now.

The answer you want is not that everything is current. It is that somebody knows what is not, and why.

4. A write-up of something that broke¶

Ask for an incident write-up from a real production system: what happened, what the customer experienced, why, and what changed afterwards. Names removed, client anonymized, no problem.

You are reading it for tone. A write-up that blames a person, a vendor or a user is a firm that has not learned anything from the incident and will not learn from yours. A write-up that names a cause, admits what was missing, and describes a change that would have prevented it, is the artifact of a team that operates things. A firm with no such document has either never run anything in production or does not write it down, and both are worth knowing.

What the refusals mean¶

None of these four is exotic and none of them exposes anything commercially sensitive, which is what makes the reluctance legible:

• “The build is complicated” usually means it lives on one person’s machine.
• “We test manually” is a real methodology on some projects and an expensive one on any project that changes; ask what happens when the manual tester is on holiday during a release.
• “We would have to check with the client” about a dependency list is a redirection; the list is about their own work, not the client’s data.
• “Nothing has broken” is not reassuring. Everything breaks. It means it broke and nobody wrote it down.

Ask us for all four. We would rather be assessed on them than on a deck, and a buyer who asks these questions is one who will be straightforward to work with, because they will notice when the work is good.