🧱 Foundations

While we have many options in choosing technology, there are a few foundational things that are prudent to put in place early. Each costs little while the system is young and a great deal to retrofit once devices are in the field. They also speed up the prototype loop: every spin is identifiable, updatable, and reproducible. An example is included with each of the items below.

• An intelligent part-number system. Every board, assembly, cable, and purchased component gets an identifier that is easy for humans to process, carries meaning, and stays stable as the design evolves. (see this scheme as an example)
• Identification and tracking for hardware in the field. Each machine and each module inside it is easily identified by both machines and people, so you can answer what sits on a customer’s floor, what went into it, and which units share a suspect batch, without sending someone to look. (see HFID)
• Remote monitoring, metrics, and control. Every machine reports what it is doing and how it is doing: cycle times, motion health, temperatures and pressures, error rates, consumable levels, firmware and configuration state. Configuration and recipes flow the other way, so a setting changes without a site visit. That data turns a support call into a diagnosis, shows a worn part before it fails, and tells your engineers which numbers to design against next. (SIOT)
• Software update designed in from the start. A dependable update path on the first boards. Deployed units require it, and it accelerates development immediately. (Yoe updater)
• Release and versioning discipline. Every firmware image, board revision, and configuration set versioned, tagged, and tied to the machines running it. A regulated customer will eventually ask you to produce this record. (release first)
• Automated, reproducible builds and releases for anything in the system. Firmware, PCBs with their BOMs and fabrication outputs, any embedded Linux, backend services, and test tooling built and released from source by automation, so anyone can rebuild what a customer is running a year from now. (GitPLM and yoe build)
• A transparent development environment. Design discussions, questions, and decisions happen where the whole team sees them: issues and pull requests next to the code, and a team-visible chat channel instead of one-to-one threads. Your code already lives in GitHub, so keep the planning and the history there too. It is how knowledge stays with the company as the team grows, and what makes outside review effective at all. (Gitea, GitHub, GitLab)
• Documentation, specs, and plans before code/design. AI generates code faster than people can review it, so every change starts with documentation, moves to a spec, and then to design and code. That order lets a reviewer see the whole system instead of one file at a time. (Doc-Driven Development)

These are simple, obvious things, but sometimes the hardest things to find the discipline to do and get right. In the rush to get the features shipped and the hard things done, we skip the basics that allow us to do it again and again, with ease and confidence.

This list is also available as a questionnaire with more reference links in the free foundations audit.