That's the normal case. We're independent and not tied to any silicon vendor, so bring the board you've already committed to and we build on it. If you haven't chosen yet, we'll help you pick — and source and configure it for you if you'd rather not deal with that at all.

It's a fixed price, quoted after a free scoping call, because the honest answer depends on your board. A mature SoC with a maintained vendor BSP is a very different job from a bare part with a vendor kernel nobody has touched in three years. A short paid audit tells you which one you have before you commit to the build.

We find that out during the audit, not during week five. If a maintained BSP exists we harden and trim it. If it doesn't, bring-up is real work and we quote it as such — or we tell you the board is a bad bet and suggest one that isn't. Either way you hear it up front.

Yes — completely. The meta-layer lives in your Git organization, the signing keys are generated and held by you, and everything sits on open-source foundations: Yocto, RAUC, U-Boot, AWS IoT. There is no subscription, no per-device runtime fee, and no proprietary layer of ours in the middle of your product.

A reasonable question to ask of anyone entrusted with a ten-year product. Nothing we deliver depends on our continued involvement: it is standard, widely-used open source, held in your repository, with a reproducible build and written documentation — not a bespoke framework that only we understand. Any competent embedded Linux team can take it forward, and we will support that handover if it becomes necessary. Eliminating that dependency is a deliberate design decision.

You can, and we often start from one. But a vendor BSP is a demonstration that the silicon works — it ships with a kernel pinned to whatever was current at tape-out, a writable rootfs, debug access left on, and no update path. Turning that into something you can safely ship, patch, and still build in 2033 is the actual work.