Your PoC works. Will your product?

Hardware design, design review and embedded firmware for teams building electronic products. Whether you are growing a proof of concept, heading to production, or chasing a board that won't behave, I can review what you have, design what you need, or help your team get there themselves — fast where speed matters, careful where mistakes get expensive. Over 15 years of designs in production, from medical imaging to connected consumer and industrial products.

Request a design review Discuss your project See what I do
One of my designs from 2015: A real-time image generation logic board for a handheld medical ultrasound device.
One of my designs from 2015: A real-time image generation logic board for a handheld medical ultrasound device.

Lessons from the bench

Does any of this sound familiar?

Every one of these is real. A few I learned the hard way on my own early designs; the rest I've found on client boards, some already in production, patched with add-ons instead of fixed at the source, at real cost in engineering time and re-certification.

Readings that are noisy, drift, or change when someone touches the enclosure. Usually layout and grounding, sometimes the sensor or front-end was never right for the job.

Battery life a fraction of the estimate. Leakage paths through pull-ups, protection parts and rails that were never meant to stay powered, or ICs on the wrong power state.

Devices that lock up, need a power cycle, or never come back from a flat battery. Missing reset supervision, power sequencing and brown-out behaviour that nobody designed for.

Units failing at the line, yield drifting down or worse, units failing in the field. Poorly planned footprints, layout, stackup or via structure. Sometimes this shows up after several thermal cycles.

Firmware that gets less stable with every feature. Usually firmware without clear interfaces and responsibilities for each module, weak thread synchronisation and insufficient test coverage.

Best part on paper is a nightmare to work with. It may offer all the features and performance at a fraction of the competitor's price, with poor documentation and support. That engineering effort is only worth it if the BOM savings at your volume cover it.

The pattern underneath

The path to a product

Time to market is essential, but so are reliability and long-term support, and optimising for the first can compromise the others. I've often seen proof-of-concept devices built on development kits grow into the final product, keeping the dev kit's schematics, layout and firmware unchanged because they "already work".

That's a great way to prove an idea, but rarely a sound foundation for a product. Development kits and example code aren't designed for the field or for a product's constraints: passing compliance, securing data, updating firmware reliably, and the robustness expected of an embedded device. Nor are they designed with the supply chain and longevity a production product needs.

How far to depart from a reference design should be an early, deliberate decision. Too often it's made reluctantly, once critical issues have already appeared.

Nordic nRF54L15 Development Kit

Services

Four ways I work with embedded engineering teams

Most engagements start with a review. It's the quickest way for both of us to find out whether I can help, but if your project already has a clear scope, we can start there.

Proving an idea

Fast prototypes, and architecture choices that won't trap you later.

→ 02 · 03

Heading to pilot or production

Design, design for test, pre-build review and certification readiness.

→ 01 · 02

Something isn't working

Diagnosis and rescue of boards and firmware already built.

→ 01 · 03

Building your team

Mentoring and technical leadership.

→ 04
01

Design review

A systems-level review before you commit to a build, or a diagnosis of a board that is already misbehaving. I look at four levels:

  • Circuit: reset and power sequencing, flat-battery recovery, logic-level compatibility, leakage paths, EMC series termination, and protection that actually protects.
  • PCB: stackup, placement, layout, return paths and manufacturability.
  • Components: whether the MCU and key parts (chargers, wireless charging, sensors, NFC, transceivers) fit the job; development environment maturity; lifecycle and supply risk.
  • Testability: a strategy across bring-up, design verification, end-of-line test and provisioning, and the jigs and tooling it needs.

You get: a written report ranked by severity, a specific fix for each issue, and a call to walk your team through it.

Ideal for: teams about to order a build, or holding a board that misbehaves for no clear reason.

02 · Core service

PCB & hardware design

If the review shows what I'd catch, this is what I'd build. From requirements to a manufacturable board: schematic, stackup, high-density and high-speed layout, EMC-aware design, BOM and manufacturability, then bring-up and debug of the first articles.

  • Source design files and manufacturing outputs, ready for your fabricator
  • A BOM checked for lifecycle and supply risk
  • Test points and test strategy planned in, not added later
  • Bring-up and debug of the first articles

Ideal for: products heading to pilot or production, or a proof of concept that needs to become a real product.

multilayerBGA / fine pitch RF-adjacentFPGA EMCDFM / DFT
03

Embedded firmware

Firmware that behaves predictably and is cheap to change. Three ways in, depending on where you are:

  • Review: structure, stability risks and test coverage of an existing codebase.
  • Architecture and planning: module responsibilities, interfaces, test strategy, and a path from proof of concept to a maintainable codebase.
  • Implementation: hands-on development, on its own or alongside your team.

Secure boot, unit tests and CI pipelines are part of how I work, not extras on the quote.

Ideal for: firmware that gets less stable with every feature, or a prototype codebase about to become the product.

ZephyrFreeRTOS MatternRF NXPC / C++
04

Mentoring & technical leadership

Someone to ask before decisions get expensive. Reviews run as teaching sessions, so your engineers keep what they learn, plus guidance on process and architecture as the product grows.

  • Design and code reviews your team learns from, not just a list of fixes
  • Regular sessions on process, architecture and tooling
  • A second opinion on the decisions that are costly to reverse

Backed by years of teaching: I created the PCB design course at Pontificia Universidad Católica, lectured computer architecture at Universidad de Chile, and tutored digital systems design at the University of Melbourne.

Ideal for: small teams without a senior hardware or firmware lead, or engineers stepping into that role.

System architecture

The decisions you pay for on every sprint that follows

Choosing a processor is not only a question of clock speed and peripheral lists. It is toolchain maturity, RTOS support, driver quality, documentation your team can actually read, vendor longevity, and the engineering hours you will spend working around whatever is missing.

I have watched a cheap, genuinely powerful part become the most expensive line on a project once development time was counted honestly. That cost never appears on the BOM.

I help define or review system architecture across hardware, firmware and user experience, against the constraints that actually bind: BOM cost, power budget, form factor, certification path, and engineering effort.

Handheld medical ultrasound prototype in early testing

Background

Who you would be working with

Medical imaging hardware, end to end

Led the electronics design of a portable ultrasound system: every PCB, including three FPGAs and the high-speed interfaces between them, plus collaborating with Verilog and firmware works. Patent US10548565B2.

Recognised engineering work

Ramón Salas Edwards award, Colegio de Ingenieros de Chile, 2016. Selected by CORFO for commercialisation training with SRI International.

Product development across industries

Nine years (2017-2026) at Tekt Industries, a Melbourne product design house, first as a hardware designer, later as a firmware developer and Team Lead. Products for clients in medical, agriculture, telecommunications, marine and connected consumer devices, covering every stage across projects, from concept and architecture to production. In a small team, that meant owning designs end to end and working directly with clients.

Passionate about sharing knowledge

Master of Engineering, University of Melbourne. Created and taught a PCB design course at Pontificia Universidad Católica; lectured computer architecture at Universidad de Chile; tutored digital systems design (FPGA and Verilog) at the University of Melbourne; and runs the RodriTech YouTube channel to share eduactional videos and his own projects.

Rodrigo Maureira

How it works

Straightforward to start

1

Tell me what worries you

A short email describing the product and the symptom. No charge, no obligation, and happy to sign an NDA before you send anything.

2

Send the design

Schematic and layout — source files or PDFs — plus stackup, BOM, and any test or certification results you already have.

3

Get findings you can act on

A written report ranked by severity, with a concrete fix for each issue, followed by a call with whoever needs to act on it.

Working remotely

I work from Chile and keep Australian business hours, so a normal working day overlaps yours in full. Most of my recent work has been delivered remotely to Australian teams.

Engagement models

  • Fixed-scope design review
  • Retained blocks of hours for ongoing support
  • Defined design or firmware projects

Contact

Send me your board

If something on this page described your product, a short email is the fastest way to find out whether I can help. I answer every enquiry personally.

info@smartdreams.cl
LinkedIn RodriTech on YouTube