The mockup changed. The invoice didn’t.

O que nos disseram

An external software development company had been contracted to build a document-processing feature.

The agreed scope was to let a user upload a PDF, run OCR against it, and extract a defined set of fields from the result.

The vendor implemented that scope against the written requirements and the UI mockup provided at the time.

Once real users began working with the system, new expectations surfaced: the ability to rotate an uploaded PDF, the ability to change its displayed size, and additional fields to extract from the OCR output.

The client updated its UI mockup to include these expectations.

We were told that this additional work was a defect in the vendor’s existing implementation, not a new requirement.

That position was not something one project member happened to say. It was also stated at the CEO level.

O que observamos

We compared the original requirements and mockup against the updated one.

Rotating an uploaded PDF, resizing its displayed view, and extracting the additional fields were not present or described in the requirements and mockup the vendor had built against.

They appeared for the first time after users began operating the system, shaped by how people actually tried to use it.

So the question was not whether the additional behavior was reasonable to want. It plainly could be.

The question was whether it had been part of what the vendor originally agreed to deliver.

On the evidence available to us, it had not been.

We then looked at how the contract treated that kind of gap. Two categories existed: specification change, and defect.

A specification change required a new estimate and a new order. The client would fund it.

A defect was treated as a failure to deliver what had already been paid for. The vendor would fund it.

The new behavior was classified as a defect.

O padrão

The classification did not describe what had happened before implementation. It decided what would happen to the cost after implementation.

Labeled a specification change, the same functionality would have required a new order, funded by the client.

Labeled a defect, the same functionality became a correction the vendor already owed under the existing contract.

The work itself did not change depending on which label was applied. Who paid for it did.

The observable sequence was:

1. Requirements and a mockup were agreed and built against.
2. Real users began operating the system.
3. New behavior became expected once real use began.
4. The mockup was updated to describe that behavior.
5. The gap between the old and new mockup was classified as a defect, not a change.
6. That classification placed the cost of the new behavior inside the existing contract.
7. The vendor, not the client, became responsible for funding it.

Nossa hipótese

The dispute we were shown was framed as a question about software quality: had the vendor delivered a working system or a defective one?

Our hypothesis was that this was not, at its core, a quality dispute.

It was a classification question with a financial answer already attached to it.

A newly discovered need and a failure to satisfy a previously agreed requirement are not the same claim, even when they produce an identical list of things to build: rotate the PDF, resize the view, extract more fields.

The first describes something nobody had asked for yet. The second describes something that was asked for and not delivered.

Under this contract, only one of those was billable to the client.

Whichever label got applied did not need to be applied in bad faith to have that effect. It only needed to be applied.

What we are not claiming

We are not asserting that the CEO, or anyone else on the client side, classified this work as a defect in order to avoid paying for it.

That motive was never something we observed, and our finding does not depend on it being true.

It is entirely possible the client genuinely believed that rotating a PDF or extracting a few more fields was the kind of behavior any reasonable implementation should have included from the start.

Reasonable people can disagree about where the boundary of an original requirement ends, especially when the requirement was defined at a high level against a single mockup.

What we could observe was not intent.

It was consequence.

And the consequence was structural: whichever party’s work carries the label “defect” absorbs the cost of the disagreement, regardless of who was right about where the original scope ended.

O que as evidências mostraram

The requirements given to the vendor described upload, OCR, and extraction of a specified set of fields.

The mockup used during implementation did not include PDF rotation, a resizable display, or the additional OCR fields.

Those behaviors appeared only after real users worked with the system, and the mockup was updated only afterward, to match what had been learned.

That sequence describes a newly discovered need. On its own, it does not describe a failure to meet the original agreement.

Classifying the gap as a defect did not change that sequence. It changed who was contractually responsible for closing it.

The disagreement was never about whether the additional behavior was worth building. It was about whose budget it came out of.

A visão da Pulsar

A defect and a specification change can look identical in a bug tracker: the same ticket format, the same expected-versus-actual framing, the same list of screens to fix.

What they are not identical in is who owes the work.

That is why the label deserves scrutiny whenever it is applied to something discovered after delivery, rather than accepted at face value.

We did not need to decide whether the client or the vendor was right about the original scope to see this. We only needed to compare what had been specified against what was later demanded, and notice that the classification—not that comparison—was what determined who paid.

A defect report is a technical claim and a financial instrument at the same time. Treat it as only the first, and the second one still gets decided—just without being examined.