Our Linux-based product boots slowly, can't be updated in the field, or nobody dares touch the build

For products running embedded Linux: an assessment of the build, boot and update story, then fixed-price sprints to fix it — Buildroot and Yocto, kernel and root filesystem, boot-time reduction, remote firmware update. Assessment AUD 6,000, sprints AUD 15,000.

PriceAssessment via the diagnostic week AUD 6,000 · Sprints AUD 15,000 per two weeks
TurnaroundAssessment in 10 business days · Typical product 1–3 sprints
PaymentAssessment paid up front; sprints 50% deposit
Next stepIntake form — I reply within one business day

Where you are

I’ve built and maintained embedded Linux platforms on Buildroot and Yocto for products in the field: kernel and root filesystem configuration, boot-time work, remote update, and the board-support customisation for NXP i.MX-class processors.

Step 1 — the assessment (diagnostic week, AUD 6,000)

A written plan: what the build actually contains, what’s blocking reproducibility, where the boot time goes, what a safe update mechanism looks like for your hardware (A/B partitions, rollback, signing), and a sprint-by-sprint plan with acceptance tests and a fixed price per sprint. Credited against the sprints if they come to more than AUD 20,000 and start within 90 days.

Step 2 — the sprints (AUD 15,000 per two weeks)

Typical shapes:

Sprint Deliverable
Reproducible build The image builds from a clean checkout in CI, pinned and documented; anyone on your team can produce a release
Boot time Measured, then cut: bootloader, kernel config, service ordering, with the numbers before and after
Remote update A/B or recovery-partition update with rollback, tested against power loss mid-update
Platform move BSP for the new module, device tree, peripherals proven end to end

What you get at the end

A build your team owns, a boot time you can quote, an update path you can trust, and a handover document your next engineer can pick up.

What’s not included