Custom SBC RFQ Template: What Engineering and Procurement Should Prepare

The fastest way to slow down a custom board project is to ask for a firm price while the product still exists as a loose feature list. “Android, 7-inch display, Wi-Fi, several serial ports” sounds specific in a meeting. To a hardware team, it leaves open the display interface, touch controller, power tree, connector placement, radio certification, serial protection, software ownership, and factory test method.

A useful custom SBC RFQ does not need to contain a finished schematic. It does need to show what the product must do, which constraints are already fixed, and where the supplier is expected to make engineering decisions. This lets procurement compare quotations on the same basis instead of comparing one supplier’s complete scope with another supplier’s board-only price.

Use the template below before requesting custom SBC development. Engineering should own the technical baseline; procurement should own commercial quantities, delivery terms, and quote normalization. Product management has to settle the priorities when cost, schedule, and features conflict.

Begin with the product, not the processor

Give the supplier two or three paragraphs describing the installed product. State who uses it, where it operates, what it connects to, and what a normal power-on sequence looks like. A wall HMI, refrigerated vending terminal, outdoor gateway, and laboratory controller can use the same processor yet need very different boards.

If the SoC has already been qualified, name it and explain why it is fixed. If it has not, provide measurable workloads: screen resolution and frame rate, video decode, camera count, application memory, database size, boot-time target, AI workload, and expected CPU load. This gives the supplier room to select an appropriate platform without quietly oversizing the BOM.

For projects that are still deciding between a module and a one-board design, settle the board architecture before asking every supplier for the same unit price. The NRE, sample schedule, production cost, height, and software risk are not equivalent.

Custom SBC RFQ input template

The RFQ should have one controlled requirements table. Mark each item as required, preferred, supplier proposal, or not applicable. That small distinction prevents a casual preference from being priced as a hard constraint.

Attach native enclosure files when possible, not only screenshots. Include display and touch datasheets, mating connector part numbers, cable drawings, old board photographs, the application APK or Linux service list, and a simple system block diagram.

Freeze interface details that affect layout

“Two USB ports” is not a complete interface requirement. State host or device role, connector type, expected current, speed, cable length, hot-plug behavior, and the peripherals used in acceptance testing. Apply the same discipline to Ethernet, serial ports, camera, audio, and display.

Mechanical information deserves equal weight. Give the supplier the maximum PCB outline, mounting datum, connector openings, component height zones, antenna keep-out, display cable bend area, and the part that carries heat away from the processor. When these details arrive after layout, even a small connector move can trigger routing changes, a new PCB, and another mechanical sample.

Define BSP and application ownership

Software scope is where apparently similar quotes diverge most. State the required Android or Linux version, expected kernel or vendor SDK baseline, drivers, boot logo, launcher, permissions, device tree, factory image, update method, and recovery behavior. Name the peripherals that must be proven on the final board.

Define acceptance in observable terms. “Wi-Fi works” is weak. “The production image reconnects after a 60-second outage and resumes the application without operator action” can be tested. The exact threshold will vary, but the RFQ needs a pass/fail condition.

NASA’s systems engineering guidance makes a useful distinction between stakeholder expectations and validated technical requirements. An OEM board is not a spacecraft, but the same habit helps: convert wishes into measurable behavior before they become contractual arguments.

State quantities as a ramp, not one number

Suppliers need prototype quantity, pilot quantity, first production order, annual forecast, and expected production life. “10,000 units” can mean a lifetime estimate or a monthly requirement; the purchasing and test strategy will differ considerably.

Include a target schedule with decision gates:

RFQ clarification complete -> schematic review -> EVT samples
EVT issues closed -> DVT revision -> pilot production approval
Pilot report accepted -> mass-production release

Ask the supplier to identify long-lead parts and MOQ-sensitive items separately. Memory, storage, wireless modules, display connectors, PMICs, and specialized terminal blocks can distort both price and schedule. A planned BOM lifecycle review should cover approved alternates, notice periods, and who validates substitutions.

Specify production evidence and deliverables

Do not leave factory testing as “100% function test.” List the functions tested on every unit, identity data written, image version recorded, fixture outputs saved, and evidence supplied with each lot. Clarify whether testing uses loopback plugs, golden peripherals, network services, cameras, displays, or customer fixtures.

Engineering deliverables may include schematic PDF, interface drawing, 3D PCBA file, connector table, BSP image, flashing tool, release notes, test report, compliance files, and change log. Source files and source code are commercial questions; put ownership and delivery timing in the RFQ.

Normalize quotations before choosing a supplier

Create a comparison sheet that separates one-time and recurring costs. For each quote, record:

• Requirement assumptions and open exceptions
• Hardware NRE, BSP NRE, fixture NRE, and enclosure tooling
• Number of samples and board revisions included
• Unit price at the same quantity and Incoterm
• Memory, storage, wireless, display, cable, and accessory inclusions
• Certification support, documentation, warranty, and field support
• Quote validity, component lead time, and payment milestones

A quote that excludes driver integration, fixture development, or a second board revision may look attractive until those tasks become unavoidable. Ask suppliers to write exclusions plainly; silence is not scope.

A practical RFQ package

Before release, the package should contain a requirements table, block diagram, interface list, mechanical files, component datasheets, software scope, test expectations, quantity ramp, schedule, and commercial questionnaire. Use one revision number and issue a change log when the baseline moves.

For an Android SBC platform, include the APK, display timing, peripheral list, boot behavior, and update plan. For Linux products, include kernel dependencies, services, storage layout, network recovery, and access to application hardware. These inputs often determine more engineering effort than the processor choice.

Final recommendation

A strong custom SBC RFQ is specific where the product is fixed and honest where it is not. It gives engineering enough detail to estimate risk and gives procurement enough structure to compare scope, price, schedule, and responsibility. If an item is unknown, label it as a supplier proposal and define when it must be decided. That is far better than hiding the uncertainty inside a firm-price request.

Frequently Asked Questions

What information is essential in a custom SBC RFQ?

At minimum, provide the product use case, operating system, display and interface requirements, power input, enclosure constraints, prototype and annual quantities, target schedule, BSP scope, production test needs, and expected engineering deliverables.

Should an RFQ specify a processor model?

Specify a processor when it is already qualified or required by software. Otherwise, describe measurable workload, display, camera, interface, power, temperature, and lifecycle needs so the supplier can propose a suitable platform without unnecessary overdesign.

How should buyers compare custom SBC quotations?

Normalize the quotations before comparing price. Check NRE inclusions, prototype quantities, revision limits, BSP and driver scope, test fixture work, documentation, certification support, tooling, unit-price assumptions, component substitutions, warranty, and production support.

Can an incomplete RFQ still receive a budgetary quote?

Yes, but it should be labeled budgetary and list every assumption. A firm quotation normally requires frozen interfaces, mechanical constraints, software scope, quantities, deliverables, acceptance criteria, and responsibility boundaries.