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.
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.
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.
- 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.
# 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.Choose one previous build and write the product idea file. Do not add features yet. The goal is focus.
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.
# 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.Create PRODUCT_SPEC.md and define exactly three must-have features. Anything else goes into “future improvements.”
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.
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.
# 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 |Create ARCHITECTURE.md and include at least one hardware diagram, one software diagram, and five risks with recovery plans.
Build the BOM & Budget
A bill of materials makes the project rebuildable. It also shows cost awareness, substitutes, and hardware decision-making.
# 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:Make BOM.md with every board, sensor, cable, resistor, supply, enclosure material, and tool required to recreate the product.
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.
config.example.json instead.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.mdCreate the folder structure above. Move old prototype files into the right places and remove unused experiments.
Add Setup Automation
A product should not require a long list of mystery commands. A setup script captures dependencies and reduces onboarding pain.
#!/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"Add setup.sh, requirements.txt, config.example.json, and a self-test command to your project.
Make It Run on Boot & Recover
A real embedded product should start itself after power loss, log what happened, and recover from ordinary failures.
# /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 -fConfigure run-on-boot behavior. Then power cycle the device and prove the product starts without manual code commands.
Design the Enclosure & Field Readiness
Even a simple project feels more real when the wires, ports, sensors, airflow, labels, and mounting plan are considered.
- 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?
# 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:Sketch or mock up the enclosure. Photograph it and add the image to docs/images/ with notes about port placement and airflow.
Test Like a Product
Final capstone testing should cover the happy path, bad inputs, hardware failure, network failure, reboot behavior, and demo readiness.
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?
# 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 / noFill out TEST_PLAN.md honestly. Do not mark a test passed unless you actually performed it.
Write Documentation & Onboarding
The README is the product manual, sales page, setup guide, troubleshooting page, and portfolio explanation all in one.
docs/images/ and reference them in the README.# 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
Ask someone else to follow only your README. Record where they get stuck, then fix the docs.
Record the Demo & Portfolio Assets
A strong capstone needs evidence. The demo should show the product working, not just talk about the idea.
- 0–10 sec: Name the product and the problem.
- 10–30 sec: Show the hardware and inputs.
- 30–65 sec: Trigger the main feature and show the output.
- 65–80 sec: Show docs, setup, or test results.
- 80–90 sec: Say what you would improve next.
# 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 linkCreate a thumbnail, wiring photo, screenshot, and 60–90 second demo script. Add them to assets/ and docs/images/.
Final Launch Package & Rubric
The final module packages the product for release and grades it like a real portfolio artifact.
| Category | Excellent | Needs work |
|---|---|---|
| Functionality | Main feature works repeatedly from cold boot. | Only works once or needs manual editing. |
| Documentation | A new user can rebuild and run the project. | Important setup/wiring steps are missing. |
| Reliability | Handles restart, bad config, and basic failure cases. | Crashes silently or cannot recover. |
| Presentation | Demo clearly shows problem, hardware, result, and proof. | Demo is vague or only describes the idea. |
| Code quality | Organized, named clearly, configurable, and logged. | Messy prototype files with hidden assumptions. |
# 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:Complete the release checklist, tag a v1.0 release in your repo, and prepare the project for portfolio review.