You Can't Contract Away the Need to Test

Every so often, a freelance job posting comes along that makes you read it twice.

Not because the electronics are terribly exotic. Because the expectations are.

This one was for a small USB-C-powered LED product. There were buttons, dimming controls, some LED boards and little displays. The usual sort of thing that sounds quite manageable when you describe it in one sentence.

The designer would be selected within twelve hours. The PCB had to be manufacturing-ready within twelve hours of starting. Then came the explanation for skipping the prototype.

Hang on. You’re too short on time to build and test one, but prepared to order a thousand before finding out whether the design works?

It’s not a thousand different mistakes you have to worry about. It’s one design mistake reproduced a thousand times. And if that happens, you’ve hardly saved time. You’ve moved the discovery of the problem to the most expensive possible moment.

Maybe there was already evidence that made skipping a prototype a reasonable risk. The brief doesn’t give us any.

And the payment terms?

So the designer carries the cost of a mistake that nobody has allowed time to uncover.

At least they offered to cover the shipping if the designer wanted the defective boards sent back.

That’s thoughtful.

But put the contractual gymnastics aside for a moment. There’s something more interesting going on here.

The brief asked for 30 W over a custom cable carrying only 5 V and ground, through a specified USB-C receptacle. Current is power divided by voltage (I = P / V), so 30 W ÷ 5 V = 6 A. The named TYPE-C-31-M-12 connector is listed with a 5 A power-current rating.

A custom cable is not inherently a bad idea. You can engineer a proprietary power connection if you understand and qualify the complete arrangement. But calling a cable custom doesn’t increase the current rating of the connector you plug it into.

Who is going to check the contact temperature at the intended current? The voltage drop? The connector and cable together, under the conditions the product will actually see?

Not on a prototype, apparently. We’re skipping that bit.

Then there’s a requirement to shut off power if consumption exceeds 50 W. At 5 V, that’s 10 A, despite the stated 30 W input budget. Perhaps there is a sensible power architecture behind that number. The brief doesn’t tell us. It doesn’t tell us how available power is measured either, even though the product is supposed to protect one load by automatically dimming other loads when power gets scarce.

That’s a control problem, not a matter of placing a few LEDs neatly on a PCB.

The thermal requirements are another little gem. The LEDs might get hot, the enclosure is plastic, and the proposed way to limit brightness is a scroll wheel. The brief even says:

Maybe it will be fine. Maybe that reduced setting really will keep the product within its thermal limits.

How would we know?

You can calculate expected dissipation and make sensible design choices. But the actual temperatures depend on the board, the enclosure, the airflow, the operating conditions and the way the product is used. At some point, somebody has to measure something.

Now, none of this proves the product couldn’t work. We haven’t seen a schematic, a layout, a prototype or a test report. We don’t know whether anyone accepted the job, whether anything was manufactured, or how it turned out.

That matters. We’re looking at a proposed decision, not documenting a product failure.

And the problem isn’t necessarily a dishonest customer or an incompetent engineer. A customer can sincerely believe that a careful drawing and an accepted manufacturing order mean the hard part is over. An engineer can sincerely believe that a familiar circuit will behave as expected.

Sometimes they’re both right.

But belief isn’t the same thing as evidence, and a contractual demand for perfection can’t turn one into the other.

What gets me about this posting isn’t just the deadline. It’s the precision of the commercial conditions compared with the uncertainty of the engineering. The time allowed is precisely defined. The payment penalty is precisely defined. Yet what constitutes an acceptable thermal result, a safe power connection or a successful power-allocation test isn’t.

There’s a strange assumption hidden in that arrangement: if you make the consequences of failure severe enough, failure somehow becomes less likely.

It doesn’t.

A good design review might catch several of these problems before fabrication. That’s valuable. Planning the measurements before routing the PCB is valuable too. So is building smaller evaluation boards to investigate the awkward parts first.

But even a well-reviewed design or a carefully made EVM is still carrying assumptions. Its job is to give us a practical way to challenge them. One successful bench test won’t establish that every production unit will work, either; characterization and production acceptance answer different questions.

The sensible response to uncertainty isn’t necessarily an endless test programme. It’s to decide which questions matter, what evidence would be sufficient for the next decision, and what risks we’re knowingly carrying forward.

In this brief, the opportunity to ask those questions had effectively been removed. The answer was expected to be yes before the hardware existed.

We don’t know how the story ended.

We do know how it began.

With a thousand boards proposed for manufacture before anyone had demonstrated that one met the requirements.

This is how false confidence begins.