A missing detail in a product page is a documentation question, not yet a reason to commission a custom product. First distinguish buying an unchanged published configuration, requesting a defined variation, and asking a supplier to develop a solution that has not been established. Those routes buy different things and need different approval decisions. Once technically suitable routes are defined, compare upfront cost and realistic purchase quantity before choosing a lower unit price.
This guide helps technical buyers and platform leads choose the scope of the next purchase. It does not rank standard and custom products or assume that a variant is available. Start with the published ResiNav products; use the Custom OEM integration page when the requirement would change the supplied item or needs a feasibility decision.
Separate an information gap from a product change
Suppose a published configuration looks relevant, but its public record does not show a connector drawing. Asking for the drawing does not change that configuration. If the drawing later shows a connection that the project cannot use, the team can consider changing its own harness, selecting another documented configuration, or asking whether a product change is feasible. These are separate decisions; do not label all three as custom development at the outset.
Conversely, a familiar model name does not make a changed item standard. A different enclosure, electrical boundary or firmware behavior needs its own scope and identity if the supplier agrees to provide it. Missing public information establishes neither support nor lack of support. Use the data-sheet review guide to keep confirmed facts separate from open fields.
Choose the purchase scope before comparing offers
The routes below are a buyer-side decision aid, not a list of customization services promised by ResiNav.
| Route | What would be purchased | When it is a sensible starting point | What must be settled before approval |
|---|---|---|---|
| Unchanged published configuration | The identified item as documented; installation work may still be needed on the buyer’s platform. | The published role fits and remaining questions concern confirmation or integration, not a known required product change. | Exact supplied configuration and included items; applicability of documents to that item; remaining installation conditions. |
| Defined variant, if offered | An existing design with an explicitly agreed difference, such as a proposed mechanical change. | A specific mismatch is known and the rest of the configuration remains a plausible basis. | Whether the change is feasible and offered; variant identity; affected evidence; ownership of integration work and acceptance. |
| Development or feasibility scope, if offered | A bounded investigation or development deliverable, not an assumed production-ready unit. | There is no established configuration that resolves the decisive requirement, or feasibility itself is uncertain. | Deliverables, decision milestones, exclusions and what a successful stage does—and does not—authorize next. |
A catalog item can still require substantial platform integration. A small-looking modification can still invalidate a drawing or a test condition. Evaluate the actual change and evidence rather than using “standard” as a synonym for ready to install, or “custom” as a synonym for better performance.
The RN-8AT-FULL-KGR-34V terminal record and RN2512-AJS-16CH-DPA system record are starting points for reviewing published configurations. Neither product name establishes a selectable connector, a custom enclosure option or the availability of a development service for your project.
Example: an enclosure conflict is not automatically a custom-electronics project
Hypothetical example, not a ResiNav offer or measured installation: a buyer’s proposed mounting tray obstructs access to a catalog item’s cable exit. The team has not yet established whether the tray can move.
- Evaluate the unchanged item first. If a revised tray preserves acceptable placement and service access, the purchase may remain a standard configuration. The tray change still needs platform review; it is not proof of GNSS performance.
- Define the smallest supplier-side difference. If the tray is fixed, ask whether a different documented configuration exists. If not, describe the required physical change and ask whether a variant can be considered. Do not assume a changed cable exit is available or technically neutral.
- Separate feasibility from supply. If the required change cannot yet be bounded, request a feasibility scope, if offered. A drawing study or prototype proposal is not the same deliverable as accepted units ready for repeat purchase.
The useful outcome is a clear route and an identified unresolved decision—not a prematurely selected model. For an agreed change, the configuration-change review guide explains how to assess evidence reuse.
Decide whether a lower custom unit price repays the upfront cost
Keep the unchanged product on the shortlist unless the alternative either solves a necessary technical constraint or earns back its extra upfront cost at a credible purchase quantity. A lower unit price alone is not enough. Compare technically acceptable routes with the same delivered scope; a cost calculation cannot make an unsuitable configuration acceptable.
Separate one-time costs from per-unit costs. One-time costs can include agreed non-recurring engineering (NRE), tooling or buyer-side integration work; recurring costs should cover the complete unit scope being compared. Include only costs that actually differ between the routes, and do not count a fee twice if it is already included in the unit price. An unknown required cost is not zero.
This distinction appears in real supplier documentation. The introduction to Taoglas’ CGGBP.35.2.A.08 datasheet states that changes can involve NRE and a minimum order quantity. That is an example of Taoglas’ stated terms, not a ResiNav fee, order minimum or customization offer.
For a first-pass comparison with constant unit prices and no minimum-order constraint, calculate:
Break-even quantity = extra one-time cost of the alternative ÷ its saving per unit. Round up to a whole unit to find the quantity at which it is no more expensive. If the alternative has both a higher upfront cost and no unit saving, increasing quantity will not create a cost break-even under those assumptions. A required technical benefit may still justify it, but that is a different reason to buy.
A worked quantity decision—not a product quotation
Hypothetical USD figures, not ResiNav pricing: assume both routes have already passed the same technical and delivery-scope screen. The unchanged route costs USD 3,000 once plus USD 800 per unit. An offered variant costs USD 12,000 once plus USD 650 per unit. These are illustrative total one-time costs for each route, not an assumption that standard products normally carry an engineering fee. Ignore financing, tax, freight and any further costs only for this limited example; an actual decision must include material differences.
- The arithmetic crossover is 60 units: (12,000 − 3,000) ÷ (800 − 650) = 60. With unrestricted ordering, each route totals USD 51,000 at that quantity.
- At 40 units, the unchanged route costs less: USD 35,000 versus USD 38,000 for the variant, before any order minimum.
- At 100 units, the variant costs less in this model: USD 77,000 versus USD 83,000. That USD 6,000 difference is a conditional calculation, not a forecast of savings.
Now suppose the variant requires a firm purchase of at least 100 units. For a 40-unit deployment, its purchase total is USD 77,000, not USD 38,000, and 60 units remain unallocated. Dividing the fee across a hoped-for future fleet does not remove that purchase commitment. The 60-unit crossover no longer describes an available order: at 60 units of demand the buyer would still purchase 100 variant units. Recalculate using the actual order minimum, pack size and price tier.
For the 40-unit case, choose the unchanged route on these cost assumptions if both routes meet the requirement and there is no separate benefit that justifies the additional spend. For a firm 100-unit requirement, the variant becomes the lower-cost candidate in this example. If 100 units is only a sales forecast, evaluate the smaller committed deployment first rather than treating all forecast units as certain purchases. Unused units are inventory, not automatically a loss or a saving; their usefulness depends on later demand and configuration continuity.
Keep an economic choice separate from a feasibility purchase
If no unchanged product meets a mandatory requirement, there is no technically equivalent standard route to use as the cheaper winner. Compare another documented configuration, an acceptable platform-side change, and a bounded feasibility scope if one is offered. A successful study or prototype does not itself establish the recurring unit price or readiness for repeat supply.
For any paid investigation, agree what the stage purchases and what decision it enables before committing to follow-on units. Taoglas’ custom antenna service description, for example, separates its design/testing process from later sample validation. Its services and deliverables are not ResiNav commitments. Use the supplier proposal comparison guide to align quote inclusions before applying the quantity calculation.
Make one route decision, then move to the right review
If the only blocker is an unpublished detail, ask for that clarification against the exact model before declaring a custom requirement. If a known requirement changes the item, describe the difference and establish whether a documented alternative or a defined variant can be considered. If feasibility remains unknown, separate the investigation decision from the later purchase decision.
Once the scope is clear, use the supplier proposal comparison guide for offer inclusions and costs, and the documentation review guide for supporting evidence. Those reviews should not substitute for deciding what is actually being bought.
Frequently asked questions
Does a published product page confirm that a configuration will fit my platform?
No. A product page provides documented information for an initial comparison. Platform fit, receiver compatibility, RF integration and installation conditions remain project-specific questions unless they are confirmed for the actual application.
Should we start with the catalog or a Custom/OEM discussion?
Start with the catalog when a published product role and its documented facts give you a credible first comparison. Start a Custom/OEM discussion when an unresolved platform, RF, physical, interface, power or environmental constraint determines the decision.
What if some engineering inputs are not available yet?
Share the information that is known and mark the rest as open. A useful early discussion distinguishes documented facts, buyer requirements and questions that still need an owner; it does not fill gaps with assumptions.
Is a Custom/OEM discussion a commitment to a special configuration?
No. It is a structured way to document project-specific requirements and identify points that need technical confirmation. It does not promise a design, performance result, certification, delivery schedule or project outcome.
Compare a published item or discuss a defined change
Open the relevant product record, then ask about the specific unresolved detail or proposed difference. The RFQ guide can help assemble the information already available.
Compare published productsAsk about your purchase scope