← Embedded Track
Embedded Systems & IoT · Course 08

Build & Ship
an Embedded Product

Turn a working prototype into a portfolio-ready embedded product with a spec, architecture, BOM, setup automation, boot service, enclosure plan, test plan, documentation, demo assets, and final release package.

Start Course 08 ← Course 07 Track complete ✓
12Modules
6Templates
ProductizationDocs + setup + tests
CapstonePortfolio release
Course Progress
0%
// final_capstone_standard

Ship the strongest project in the track.

This course is not another beginner tutorial. It is the finishing lab for the full Embedded Systems & IoT track. The goal is to take one working prototype and make it understandable, rebuildable, testable, presentable, and reliable enough to show in a portfolio.

DefineProduct idea, spec, MVP, out-of-scope list
BuildClean repo, setup script, service, enclosure plan
ProveTest plan, cold boot, failure handling, demo
ShipREADME, BOM, assets, release checklist
Module 01

Choose Your Product

The final course starts by choosing one prototype from the track and turning it into a product with a clear user, purpose, and finish line.

🚀 What counts as a product?
A product is not just code that runs once. For this capstone, a product is a device someone else could understand, rebuild, test, and demo without needing you standing beside them. It can be simple, but it must be complete.
🧭 Good capstone candidates

Smart room monitor

ESP32 or Pi reads motion, temperature, light, or air quality and publishes status to a dashboard.

Network appliance

Raspberry Pi runs a useful local service such as monitoring, dashboarding, backup, or filtering.

Robot rover

Motor control, obstacle detection, and a clear control loop with documented wiring.

AI camera

Camera capture, object/person detection, event logging, and notification behavior.

🛑 Avoid these traps
  • Too broad: "Smart home system" is too vague. "Door monitor with local dashboard" is better.
  • Too dependent: Avoid a product that only works when five cloud services are perfect.
  • Too fragile: If one loose wire ruins the demo, plan strain relief, enclosure, and restart behavior.
🧩 Template: PRODUCT_IDEA.md
# Product Idea

Product name:
Target user:
Problem solved:
One-sentence promise:

Chosen prototype:
Why this one:

MVP features:
- 
- 
- 

Out of scope:
- 
- 

Success criteria:
- The device can be powered on from cold boot.
- The main feature works without manual code edits.
- A new user can follow the README and run it.
- A 60-90 second demo clearly shows the product value.
🧪 Lab: Pick the capstone product

Choose one previous build and write the product idea file. Do not add features yet. The goal is focus.

🧠 Quick Check
What makes a prototype ready to become a capstone product?
Module 02

Write the Product Spec

The product spec turns a cool idea into a build contract. It tells the learner what must be true when the course is finished.

📌 Spec versus notes
Random notes describe what you were thinking. A spec describes what the product must do. It becomes the source of truth for testing, documentation, and the final demo.
✅ Acceptance criteria
Acceptance criteria are pass/fail statements. "Looks nice" is not testable. "Dashboard shows a new temperature reading within 10 seconds of refresh" is testable.
🧩 Template: PRODUCT_SPEC.md
# Product Spec

## 1. Product Summary
Name:
One-liner:
Target user:
Primary environment: home / classroom / lab / field / desk

## 2. Problem
What problem does this solve?
Why does the problem matter?
What happens today without this device?

## 3. MVP Features
| Feature | User value | Acceptance test | Priority |
|---|---|---|---|
| | | | Must |
| | | | Must |
| | | | Should |

## 4. Out of Scope
- 
- 
- 

## 5. Operating Conditions
Power source:
Network required? yes / no
Expected runtime:
Indoor/outdoor:
Temperature or placement constraints:

## 6. Success Criteria
- 
- 
- 

## 7. Demo Criteria
In the final demo, viewers must be able to see:
- The device powering on.
- The main input or sensor working.
- The output, dashboard, notification, motion, or AI result.
- The documentation and repo structure.
🧪 Lab: Write the spec before building

Create PRODUCT_SPEC.md and define exactly three must-have features. Anything else goes into “future improvements.”

🧠 Quick Check
Which acceptance criterion is strongest?
Module 03

Plan the Architecture & Risks

A product needs a visible plan: hardware blocks, software blocks, data flow, power flow, and the places where failure can happen.

🧩 Four diagrams to think through

Hardware diagram

Board, sensors, actuators, power supply, display, camera, and connections.

Software diagram

Scripts, services, dashboard, database, API, model, scheduler, and logs.

Data flow

Where data starts, how it is processed, where it is stored, and how the user sees it.

Power flow

Power source, voltage levels, regulators, current-heavy components, and safety limits.

⚠️ Risk register
Every embedded product has risks: bad Wi-Fi, brownouts, overheating, loose wires, sensor noise, stuck motors, full SD cards, or broken dependencies. Writing risks down early makes the device more reliable.
🧩 Template: ARCHITECTURE.md
# Architecture

## Hardware Blocks
- Controller board:
- Sensors:
- Actuators / outputs:
- Power source:
- Network connection:
- Enclosure / mounting:

## Software Blocks
- Main application:
- Background service:
- Dashboard / UI:
- Data storage:
- Notification path:
- Logs:

## Data Flow
Input -> Processing -> Storage -> Output

Example:
Sensor reading -> Python service -> SQLite / JSON log -> Web dashboard

## Power Flow
Power source -> regulator / board -> sensors -> actuators

## Risk Register
| Risk | Impact | Prevention | Recovery |
|---|---|---|---|
| Wi-Fi disconnects | Dashboard stops updating | Local cache | Auto reconnect / retry |
| Loose sensor wire | Bad readings | Strain relief | Error message + status LED |
| Service crashes | Product stops | systemd restart | Logs + auto restart |
🧪 Lab: Draw the product map

Create ARCHITECTURE.md and include at least one hardware diagram, one software diagram, and five risks with recovery plans.

🧠 Quick Check
Why include a risk register in a capstone?
Module 04

Build the BOM & Budget

A bill of materials makes the project rebuildable. It also shows cost awareness, substitutes, and hardware decision-making.

💵 Why a BOM matters
The BOM answers: What parts did you use? How many? Why those parts? What did it cost? What can be substituted? Without this, another learner cannot rebuild the project confidently.
🔋 Include a power budget
For embedded work, cost is not enough. List voltage and current assumptions. Motors, servos, LEDs, cameras, and radios can draw more current than beginners expect.
🧩 Template: BOM.md
# Bill of Materials

## Parts List
| Part | Qty | Purpose | Est. cost | Substitute | Notes |
|---|---:|---|---:|---|---|
| | 1 | | $ | | |
| | 1 | | $ | | |

## Tools Used
- 
- 

## Power Budget
| Component | Voltage | Estimated current | Notes |
|---|---:|---:|---|
| Controller board | | | |
| Sensor | | | |
| Motor / output | | | |

Estimated total current:
Power supply chosen:
Why this supply is safe:

## Cost Summary
Prototype cost:
Nice-to-have upgrades:
Minimum build cost:

## Purchasing Notes
Search terms:
Part links or supplier notes:
Known compatibility warnings:
🧪 Lab: Create a rebuildable parts list

Make BOM.md with every board, sensor, cable, resistor, supply, enclosure material, and tool required to recreate the product.

🧠 Quick Check
What is the best reason to include substitute parts in a BOM?
Module 05

Prepare the Repository

A clean repository is part of the product. It tells users where the code lives, where docs live, and how to safely configure the device.

📁 Recommended structure
A portfolio project should not be one folder full of mystery files. Separate source code, docs, assets, setup scripts, tests, and wiring notes.
🔐 Configuration rule
Never commit real passwords, API keys, Wi-Fi credentials, tokens, or private endpoints. Commit a safe config.example.json instead.
🧩 Template: Repository tree
embedded-product/
├── README.md
├── PRODUCT_SPEC.md
├── ARCHITECTURE.md
├── BOM.md
├── TEST_PLAN.md
├── RELEASE_CHECKLIST.md
├── config.example.json
├── setup.sh
├── src/
│   ├── main.py
│   ├── sensors.py
│   ├── outputs.py
│   └── dashboard.py
├── docs/
│   ├── wiring.md
│   ├── setup.md
│   ├── troubleshooting.md
│   └── images/
├── assets/
│   ├── thumbnail.png
│   └── demo-script.md
└── tests/
    ├── hardware-checklist.md
    └── smoke-test.md
🧪 Lab: Clean the project folder

Create the folder structure above. Move old prototype files into the right places and remove unused experiments.

🧠 Quick Check
Why use config.example.json instead of committing your real config?
Module 06

Add Setup Automation

A product should not require a long list of mystery commands. A setup script captures dependencies and reduces onboarding pain.

🧰 What setup should do
The setup process should install packages, create a virtual environment when needed, copy example config files, and run a first sanity check.
🧪 Keep it boring
Setup automation should be predictable. Avoid clever scripts that hide errors. Print clear messages, stop on failure, and tell the user what to do next.
🧩 Template: setup.sh
#!/usr/bin/env bash
set -e

echo "== TeqStudy Embedded Product Setup =="

if ! command -v python3 >/dev/null 2>&1; then
  echo "Python 3 is required. Install it first."
  exit 1
fi

python3 -m venv .venv
source .venv/bin/activate
python -m pip install --upgrade pip

if [ -f requirements.txt ]; then
  pip install -r requirements.txt
fi

if [ ! -f config.json ] && [ -f config.example.json ]; then
  cp config.example.json config.json
  echo "Created config.json from config.example.json"
fi

echo "Running smoke test..."
python src/main.py --self-test || {
  echo "Self-test failed. Check wiring, config, and logs."
  exit 1
}

echo "Setup complete. Next: edit config.json, then run ./start.sh"
🧪 Lab: Make first-run setup repeatable

Add setup.sh, requirements.txt, config.example.json, and a self-test command to your project.

🧠 Quick Check
What should a setup script do when a required command fails?
Module 07

Make It Run on Boot & Recover

A real embedded product should start itself after power loss, log what happened, and recover from ordinary failures.

🧱 The product behavior standard
After unplugging and plugging the device back in, the main service should start without opening an editor. If it crashes, it should restart. If it cannot start, logs should explain why.
📜 Logs are product features
Logs are not just for developers. They are how a user, maintainer, or future employer sees that you designed the device for real operation.
🧩 Template: systemd service example
# /etc/systemd/system/teq-device.service
[Unit]
Description=TeqStudy Embedded Product Service
After=network-online.target
Wants=network-online.target

[Service]
WorkingDirectory=/home/pi/embedded-product
ExecStart=/home/pi/embedded-product/.venv/bin/python src/main.py
Restart=always
RestartSec=5
User=pi
Environment=PYTHONUNBUFFERED=1

[Install]
WantedBy=multi-user.target

# Commands
# sudo systemctl daemon-reload
# sudo systemctl enable teq-device
# sudo systemctl start teq-device
# journalctl -u teq-device -f
🧪 Lab: Cold boot test

Configure run-on-boot behavior. Then power cycle the device and prove the product starts without manual code commands.

🧠 Quick Check
What should happen if the main service crashes?
Module 08

Design the Enclosure & Field Readiness

Even a simple project feels more real when the wires, ports, sensors, airflow, labels, and mounting plan are considered.

🔩 Enclosure questions
  • Can the power cable be pulled without ripping wires loose?
  • Can the sensor see, breathe, touch, or measure what it needs?
  • Can the board cool itself?
  • Can the user reach reset, USB, HDMI, or buttons if needed?
  • Can the device be mounted or placed safely?
🏷️ Label everything
Good labels reduce mistakes. Label ports, power input, sensor direction, LED meanings, and button behavior. A product someone can use safely is better than a pretty mystery box.
🧩 Template: ENCLOSURE_PLAN.md
# Enclosure Plan

## Physical Layout
Board location:
Sensor location:
Output/display location:
Power input location:
Cable exit points:
Mounting plan:

## Safety and Reliability
Strain relief method:
Ventilation / heat plan:
Protection from shorts:
Access to reset/power:

## User-Facing Labels
- Power:
- Status LED:
- Sensor direction:
- Button behavior:

## Maintenance
How to open the enclosure:
How to replace the SD card / battery / sensor:
How to check logs:
🧪 Lab: Build a paper or cardboard enclosure prototype

Sketch or mock up the enclosure. Photograph it and add the image to docs/images/ with notes about port placement and airflow.

🧠 Quick Check
Why is sensor placement part of product design?
Module 09

Test Like a Product

Final capstone testing should cover the happy path, bad inputs, hardware failure, network failure, reboot behavior, and demo readiness.

✅ Test categories

Smoke test

Does the device start and perform the core action?

Hardware test

Do sensors, buttons, displays, motors, cameras, and LEDs respond?

Recovery test

What happens after power loss, Wi-Fi loss, or service crash?

User test

Can another person follow the README and use the device?

🔥 Soak test
Run the device longer than a demo. Even a 2-hour test can reveal memory leaks, overheating, log spam, power instability, or poor reconnection behavior.
🧩 Template: TEST_PLAN.md
# Test Plan

## Smoke Test
| Test | Steps | Expected result | Pass/Fail | Notes |
|---|---|---|---|---|
| Cold boot | Unplug, plug in, wait | Service starts | | |
| Main feature | Trigger input | Output appears | | |

## Hardware Tests
| Component | Test | Expected result | Pass/Fail |
|---|---|---|---|
| Sensor | | | |
| Output | | | |

## Failure Tests
| Failure | What you do | Expected recovery | Pass/Fail |
|---|---|---|---|
| Wi-Fi lost | Disconnect network | Device retries / local mode | |
| Service crash | Kill service | systemd restarts | |
| Bad config | Rename config | Clear error shown | |

## Soak Test
Start time:
End time:
Issues found:
Fixes applied:

## Demo Test
Can the final demo be completed in 90 seconds? yes / no
🧪 Lab: Run the pass/fail test sheet

Fill out TEST_PLAN.md honestly. Do not mark a test passed unless you actually performed it.

🧠 Quick Check
Which test best proves the product can recover after power loss?
Module 10

Write Documentation & Onboarding

The README is the product manual, sales page, setup guide, troubleshooting page, and portfolio explanation all in one.

🧑‍🏫 Write for a new builder
Assume the reader is smart but has never seen your desk. Tell them what hardware they need, how to wire it, how to install it, how to run it, and what success looks like.
📸 Use images
A wiring photo, screenshot, diagram, or short GIF can prevent confusion faster than five paragraphs. Store visuals in docs/images/ and reference them in the README.
🧩 Template: README.md
# Project Name

One-sentence product promise.

## What It Does
- 
- 
- 

## Demo
Screenshot or demo video link:

## Hardware Required
See BOM.md for full parts list.

## Wiring
Add diagram/photo here.

## Setup
```bash
git clone <repo-url>
cd embedded-product
chmod +x setup.sh
./setup.sh
```

## Configuration
Copy config.example.json to config.json and edit values.

## Run
```bash
python src/main.py
```

## Run on Boot
Explain service setup or link to docs/setup.md.

## Testing
See TEST_PLAN.md.

## Troubleshooting
| Problem | Likely cause | Fix |
|---|---|---|
| Device does not boot | Power supply issue | Use rated supply |
| No sensor data | Wiring/config | Check wiring.md |

## Future Improvements
- 
- 

## Credits / License
🧪 Lab: Make the project rebuildable from the README

Ask someone else to follow only your README. Record where they get stuck, then fix the docs.

🧠 Quick Check
What is the README’s job in the final capstone?
Module 11

Record the Demo & Portfolio Assets

A strong capstone needs evidence. The demo should show the product working, not just talk about the idea.

🎥 90-second demo structure
  1. 0–10 sec: Name the product and the problem.
  2. 10–30 sec: Show the hardware and inputs.
  3. 30–65 sec: Trigger the main feature and show the output.
  4. 65–80 sec: Show docs, setup, or test results.
  5. 80–90 sec: Say what you would improve next.
💼 Portfolio polish
Your portfolio page should include a thumbnail, one-liner, stack, hardware list, screenshots, demo link, GitHub link, and two or three honest engineering challenges you solved.
🧩 Template: DEMO_SCRIPT.md
# Demo Script

## Product Name

## 0-10 sec: Problem
This device helps [user] solve [problem] by [promise].

## 10-30 sec: Hardware Tour
Controller:
Sensors:
Outputs:
Power:

## 30-65 sec: Live Demo
Action I will trigger:
Expected device behavior:
What viewers should watch for:

## 65-80 sec: Productization Proof
Show README / BOM / test plan / service logs.

## 80-90 sec: Next Step
If I had another week, I would improve:

## Assets Needed
- thumbnail image
- wiring photo
- dashboard screenshot
- short demo video
- GitHub repo link
🧪 Lab: Create the launch assets

Create a thumbnail, wiring photo, screenshot, and 60–90 second demo script. Add them to assets/ and docs/images/.

🧠 Quick Check
What should the demo prove?
Module 12

Final Launch Package & Rubric

The final module packages the product for release and grades it like a real portfolio artifact.

📦 Final package contents
By the end, the repo should include source code, setup automation, docs, BOM, architecture, test plan, enclosure plan, demo assets, and release checklist. The device should run from cold boot and survive ordinary failure cases.
🧮 Final rubric
CategoryExcellentNeeds work
FunctionalityMain feature works repeatedly from cold boot.Only works once or needs manual editing.
DocumentationA new user can rebuild and run the project.Important setup/wiring steps are missing.
ReliabilityHandles restart, bad config, and basic failure cases.Crashes silently or cannot recover.
PresentationDemo clearly shows problem, hardware, result, and proof.Demo is vague or only describes the idea.
Code qualityOrganized, named clearly, configurable, and logged.Messy prototype files with hidden assumptions.
🧩 Template: RELEASE_CHECKLIST.md
# Release Checklist

## Product Files
- [ ] README.md complete
- [ ] PRODUCT_SPEC.md complete
- [ ] ARCHITECTURE.md complete
- [ ] BOM.md complete
- [ ] TEST_PLAN.md complete
- [ ] ENCLOSURE_PLAN.md complete
- [ ] DEMO_SCRIPT.md complete
- [ ] config.example.json included
- [ ] setup.sh tested
- [ ] no secrets committed

## Device Checks
- [ ] cold boot passes
- [ ] main feature passes
- [ ] logs are readable
- [ ] bad config produces clear error
- [ ] network loss behavior tested
- [ ] enclosure/wiring is safe enough for demo

## Portfolio Checks
- [ ] thumbnail added
- [ ] screenshots added
- [ ] demo video recorded
- [ ] GitHub description updated
- [ ] resume bullet written

## Final Reflection
What worked:
What failed:
What you fixed:
What you would build next:
🧪 Lab: Submit the final product package

Complete the release checklist, tag a v1.0 release in your repo, and prepare the project for portfolio review.

🧠 Quick Check
What is the strongest final capstone submission?