What an OEM Has to Decide Before Anybody Can Quote a Custom Sensor

Most requests for a custom sensor arrive the same way. A measurement range, a resolution, a maximum size, sometimes a target price and an annual quantity. It is a serious list, written by somebody who knows their instrument, and every number in it is true.

It also cannot be quoted.

Not because anything is missing on the engineering side. Because the cost of a custom sensor is almost never in the sensing. The five decisions that set the price belong to you rather than to us, and none of them is electronics.

Why the specification you sent cannot price a custom sensor

Measuring something to a stated accuracy is usually the easy half. Sensing elements exist, their behaviour is public, and the error budget is arithmetic.

The hard half is everything around the measurement. Where the thing lives. How it gets power and attention. Who collects the reading. How many you need, and who carries the regulatory weight at the end.

Those parts move a quote by a factor, not by a percentage. A supplier cannot decide any of them for you either. That is why quotes stall, with both sides waiting politely for somebody else to speak first.

A custom sensor is rarely expensive because it is custom. It gets expensive when nobody has decided where it lives.

Here are the five, in the order they usually need answering.

One: where the custom sensor physically goes

Not the instrument. The place inside the instrument, with the things that are next to it.

This single answer sets the antenna, the overall size, the material it can be made of, the temperature it has to survive and whether there is metal in the way. We have written before that the radio window is a mechanical decision, and that is exactly what this is. A sensor that fits beautifully in a space nobody has reserved for it is a sensor that gets redesigned twice.

If the location is still open, say so. "Somewhere in this assembly, we will decide later" is a legitimate answer, and it is a completely different project from "under this cover, eight millimetres from the heater".

Two: who reads it, and when

A reading has to be collected by something. That something might be the instrument itself, a technician with a phone during a service visit, a fixed reader on a production line, or a handheld used once a year.

Each of those is a different product. They differ in protocol, in how much energy reaches the sensor, in how often you get data and in what your own customer has to install. The sensing element can be identical across all four, and the cost of the custom sensor is not.

This is also where the honest conversation about frequency of data happens. A measurement once per service visit and a measurement every ten seconds are not the same requirement with a different number in it.

Three: what happens to the reading once you have it

Where does the number go, and who acts on it?

If it lands in your instrument's own software and changes what the instrument does, that is one architecture. If it has to reach a maintenance system, or a customer's network, or a report somebody signs, that is another, and the sensor is the smallest part of it. We wrote about that gap between a reading and a work order.

A reading nobody consumes is traffic. It is surprisingly common to specify a sensor in detail before deciding who will ever look at what it produces.

Four: how many, and for how long

Two numbers that change everything, and that most enquiries leave out or guess.

Annual quantity decides whether this is a custom design or a variant of something that exists. It also decides who pays for the non-recurring work and over how many units it gets spread.

Product lifetime decides something less obvious: whether the parts you choose today will still be available when you are still shipping. A ten year instrument with a component that goes obsolete in year three is a problem you buy at the start and pay for in the middle. That is the same seam we described between a prototype and five hundred units.

Five: who signs for the finished product

The sensor goes inside something that somebody sells. That somebody declares that the finished product complies, and that signature does not transfer just because a component arrived with paperwork.

Deciding this early changes what we build, not just what we write at the end. It decides what evidence has to travel with the sensor. It decides which conditions of use you have to state and then hold. And it decides what happens to your file when somebody changes the enclosure a year later.

Teams that answer this one in month one spend less than teams that answer it in month nine. That is the whole reason it is on this list.

What a custom sensor quote looks like once you have the five

Specific, and smaller than people expect.

With the five answered, a proposal can say what we build, what we test, what stays outside the scope, and what the first step costs. Without them, any number a supplier gives you is a guess wrapped in confidence. The gap between that guess and the real figure shows up later, when changing direction costs real money.

If two or three of the five are genuinely undecided, that is not a reason to wait. It is a reason to turn those decisions into a small piece of paid work. That is a much cheaper quarter than a full development that everybody re-scopes halfway through.

Where to start

Write the five answers down in a single page, even roughly. Most teams discover that two of them are already decided, two are opinions that nobody has confirmed, and one has never been discussed.

That page is enough for us to tell you whether this is a product variant, a custom sensor, or a project that should not start yet. If the undecided ones are blocking, that is exactly what a paid scoping study is for, and it ends in a document you own. You can also read how we work across hardware, firmware, software and radio.

Next week: why a tag can have all the energy it needs and still report nothing.