Budgeting, Sourcing, and Classroom Logistics¶
Summary¶
This chapter helps educators plan and run Learning STEM with Raspberry Pi Hardware labs at classroom scale. It covers project budgeting, the bill of materials, and component sourcing, including vendor comparison, bulk discounts, and component substitution strategies for coping with the 2025-2026 RAM shortage and its associated lead times. It covers classroom kit organization, storage and inventory, shared component bins, loaner equipment policies, and funding sources such as grants and donated hardware, along with safety guidelines (electrical and battery safety) and practical classroom-management concerns like time management, lab station setup, and differentiated instruction. Educators finishing this chapter will be able to build a realistic budget and sourcing plan for a Learning STEM with Raspberry Pi Hardware unit at their own school or program.
Concepts Covered¶
This chapter covers the following 26 concepts from the learning graph:
- Project Budgeting
- Bill Of Materials
- Component Sourcing
- Vendor Comparison
- Bulk Discount
- Component Substitution
- Supply Chain Shortage
- Lead Time
- Classroom Kit Organization
- Storage And Inventory
- Shared Component Bin
- Loaner Equipment Policy
- Grant Funding
- Donor Sourced Hardware
- Cost Per Student
- Reusable Versus Consumable
- Kit Checklist
- Damage And Repair Plan
- Safety Guidelines
- Electrical Safety
- Battery Safety
- Classroom Time Management
- Lab Station Setup
- Group Size Planning
- Differentiated Instruction
- Assessment Rubric
Prerequisites¶
This chapter builds on concepts from:
- Chapter 1: Computational Thinking and Debugging for Physical Computing
- Chapter 2: Choosing the Right Raspberry Pi Product
- Chapter 3: Breadboard Wiring and Electrical Fundamentals
- Chapter 7: Building and Programming a No-Display STEM Robot
Let's Talk Budgets
This chapter is for you, the educator: the budget spreadsheet chapter, the storage-bin chapter, the safety-briefing chapter. Every superpower a student unlocks in this book started with someone like you deciding it was worth the cost, the shelf space, and the class period. Let's build a plan!
Every project earlier in this book listed an approximate price, from a $4 Pico to a $70 AI HAT+. That's useful for one student building one project. Planning for twenty-five students building the same project at once is a different problem entirely, and this chapter treats it with the same seriousness as any wiring diagram. The learning outcomes tagged [Educator] throughout this book's course description are exercised directly in this chapter: budgeting, sourcing, storage, safety, and the classroom-management decisions that make a lab period actually run on schedule.
Building a Realistic Project Budget¶
Project budgeting is the process of estimating, in advance, every dollar a project will cost before committing to it — not just the headline component price, but shipping, tools, spares, and the cost of the mistakes a first-time builder is bound to make. Budgeting for one kit built once is straightforward; budgeting for thirty kits built by thirty students, some of whom will short a wire or drop a board, requires planning for both the expected cost and a reasonable margin above it.
The specific document that budgeting is built from is a bill of materials (BOM): an itemized list of every part a single project requires, each with its quantity, unit price, and a sourcing note. A NeoPixel breadboard kit's BOM, for example, lists one Pico, one NeoPixel strip, one breadboard, a handful of jumper wires, and a USB cable — nothing assumed, nothing left to memory.
Multiplying a single BOM's total price by the number of students in a class produces the number that actually drives a program's approval decision: cost per student, the total project cost divided across every student who will build one. A $22 BOM feels very different at a cost per student of $22 for one section of twelve students than it does across six sections of thirty, and shared components — covered later in this chapter — can lower that number substantially without changing what any individual student experiences.
Berry's Key Insight
Cost per student isn't a fixed fact about a hardware tier — it's a lever you control. The same Tier 2 robot kit can cost very different amounts per student depending on whether you buy one at a time or negotiate a bulk order, and whether every item lives in an individual kit or some of it comes from a shared bin. Sourcing decisions move this number more than switching tiers usually does.
Before comparing cost per student across the book's five hardware tiers, remember that this figure is simply a BOM's total divided by class size. The chart below applies exactly that math using approximate per-tier pricing from earlier chapters.
Diagram: Cost Per Student by Hardware Tier¶
Run the Cost Per Student by Hardware Tier MicroSim fullscreen
Cost Per Student by Hardware Tier (bar chart)
Type: chart
sim-id: cost-per-student-by-hardware-tier
Library: Chart.js
Status: Specified
Learning objective: Students will analyze (Bloom L4: Analyze) how cost per student varies across the book's five hardware tiers to select a budget-appropriate project for a given class size.
Canvas: 700x450px, responsive — use Chart.js's built-in responsive: true and maintainAspectRatio: false options inside a fixed-height wrapper <div> so the chart reflows on window resize without overflowing.
Data: a vertical bar chart with one bar per hardware tier: "Tier 1: Pico Breadboard" (~\(18 illustrative BOM), "Tier 2: Pico Robot Kit" (~\)27), "Tier 3: Specialty Pico Project" (~\(25), "Tier 4: Pi 500+" (~\)180), "Tier 5: Pi 5 + AI HAT+" (~$260). Bars colored using the book's accent palette (raspberry #C2185B through copper gold #D4AF37). Y-axis labeled "Approximate Cost per Student (USD)." A caption below the chart notes that these are illustrative, approximate figures that should be updated with current vendor pricing before use.
Controls: a <select> HTML dropdown labeled "Class Size" with options 10, 20, 30 (default 20) placed above the chart, wired to a plain onchange handler.
Interaction: clicking any bar opens an infobox below the chart listing that tier's approximate BOM breakdown (2-4 major line items, e.g. Tier 5 shows "Pi 5 board, AI HAT+ accelerator, camera module, cooling") and recalculates a "Total for this class" figure using the current class-size dropdown value. Changing the class-size dropdown updates that total figure live for whichever bar's infobox is currently open, without requiring the bar to be re-clicked.
Implementation: Chart.js bar chart with an onClick handler that maps the clicked bar's index to a small JavaScript array of BOM breakdown objects. Recompute the displayed total as perStudentCost * classSize whenever the dropdown's onchange fires.
Sourcing Components: Vendors, Discounts, and Substitutions¶
Knowing a BOM's total cost is only half the job; actually acquiring the parts is component sourcing — identifying where each item on a BOM can be purchased, at what price, and how reliably. Sourcing usually means choosing among several options through vendor comparison: weighing multiple suppliers (the manufacturer directly, a specialized electronics distributor, a general online marketplace) against each other on price, shipping time, minimum order quantity, and return policy, rather than defaulting to whichever listing appears first in a search.
Vendor comparison usually turns up an option a single hobbyist buyer never sees: a bulk discount, a reduced per-unit price offered when a buyer orders a large enough quantity at once — often the difference between a $22 per-kit sensor and a $15 per-kit sensor once an order crosses twenty or thirty units. Ordering an entire class's components in one bulk purchase, rather than one kit at a time, is usually the single biggest lever an educator has over cost per student.
Sourcing doesn't always go as planned, and when a specified part is unavailable, delayed, or has jumped in price, component substitution is the practice of swapping in a different, usually cheaper or more available, part that serves the same function well enough for the lesson's actual learning objective — a generic breadboard-friendly RGB LED instead of a full NeoPixel strip for a lesson that's really about PWM, not about addressable LED protocols specifically.
Now that all three sourcing terms are defined, the table below compares the vendor options a comparison typically weighs against each other.
| Vendor Type | Typical Price | Typical Lead Time | Bulk Discount Available |
|---|---|---|---|
| Manufacturer direct | Lowest at volume | Longer, especially during a shortage | Often, above a minimum order size |
| Specialized electronics distributor | Moderate | Moderate, usually reliable | Sometimes, at lower thresholds than a manufacturer |
| General online marketplace | Highest per unit | Fastest for single kits | Rare |
Before pulling this all together into an actual number, it helps to see project budgeting, bulk discounts, and cost per student combined into one interactive tool rather than three separate ideas.
Diagram: Classroom Budget Calculator¶
Run the Classroom Budget Calculator MicroSim fullscreen
Classroom Budget Calculator (MicroSim)
Type: microsim
sim-id: classroom-budget-calculator
Library: p5.js
Template: https://github.com/dmccreary/economics-course/tree/main/docs/sims/opportunity-cost-calculator
Status: Specified
Learning objective: Students will apply (Bloom L3: Apply) class size, per-kit price, and bulk discount rate to compute a realistic total project cost and cost per student.
Canvas: 700x420px default, responsive — recompute layout from windowWidth in windowResized(), stacking the controls above the result panel on screens narrower than 480px.
Layout: a control panel on the left (or top, on narrow screens) and a large result panel on the right (or bottom) showing "Total Cost" and "Cost per Student" as large readable numbers that update live as controls change.
Controls: a createSlider() labeled "Number of Students" (range 5-150, default 25); a createSlider() labeled "Base Price per Kit ($)" (range 5-300, default 25); a createCheckbox() labeled "Order in Bulk (25+ units)"; when checked, a createSlider() labeled "Bulk Discount (%)" (range 0-40, default 15) becomes enabled and reduces the effective per-kit price used in the calculation.
Interaction: the result panel recalculates on every control change: effectivePrice = basePrice * (1 - (bulkEnabled ? discountPercent/100 : 0)), totalCost = effectivePrice * numStudents, costPerStudent = totalCost / numStudents (equal to effectivePrice but displayed separately for clarity). Crossing the 25-unit bulk-eligible threshold on the "Number of Students" slider while the bulk checkbox is checked visually highlights the discount slider with a colored border and a small label reading "Bulk pricing active," reinforcing that the discount only applies at sufficient volume in a real vendor relationship.
Implementation: p5.js, all calculations performed each draw() frame from current control values (cheap enough to recompute continuously rather than caching), values formatted with nf() for consistent currency display. Parent all controls to the enclosing <div> and reposition them inside windowResized().
Navigating the Supply Chain Shortage¶
The course description for this book is upfront about a real complication: prices for some Raspberry Pi hardware, especially boards and HATs, have risen above their historical lows during the 2025-2026 period. That's an example of a broader pattern educators need to plan around: a supply chain shortage, a period during which manufacturing capacity, raw materials, or logistics can't keep pace with demand for a component, driving prices up and availability down, sometimes for months at a time. The shortage behind this book's current pricing is tied to constrained RAM production, which affects RAM-dependent boards far more than it affects a $4 Pico with modest memory needs.
A shortage's most disruptive effect on classroom planning usually isn't price — it's lead time: the elapsed time between placing an order and actually receiving the component, which can stretch from days to many weeks during a shortage. A unit planned around a six-week school term can be derailed entirely by a part with a ten-week lead time, which is exactly why tracking lead times, not just prices, belongs in every classroom budget plan.
Berry's Tip
Order hardware the moment a unit is approved, not the week before class starts. A part with a two-week lead time today can slide to six weeks if a shortage tightens further — and a small buffer of spare parts costs far less than a delayed lesson.
Diagram: Component Lead Time Planner¶
Run the Component Lead Time Planner MicroSim fullscreen
Component Lead Time Planner (interactive timeline)
Type: timeline
sim-id: component-lead-time-planner
Library: vis-timeline
Status: Specified
Learning objective: Students will evaluate (Bloom L5: Evaluate) sourcing options based on lead time to decide when a classroom order must be placed relative to a unit's start date.
Canvas: 700x320px, responsive — vis-timeline's built-in responsive container sizing combined with a window.addEventListener('resize', () => timeline.redraw()) call.
Layout: a horizontal timeline with "today" marked at the left edge and a fixed "Unit Start Date" marker (configurable, default 6 weeks out) drawn as a vertical reference line. Four horizontal bands, one per sourcing option, each drawn as a colored bar starting at "today" and extending for that option's typical lead time: "Manufacturer direct (in shortage)" (8-10 weeks), "Manufacturer direct (normal)" (2-3 weeks), "Specialized distributor" (1-2 weeks), "General marketplace" (2-5 days).
Controls: a <input type="range"> HTML slider labeled "Weeks Until Unit Start" (range 1-12, default 6) that moves the "Unit Start Date" reference line.
Interaction: any sourcing band whose bar extends past the current "Unit Start Date" line is automatically highlighted in a warning color (matching the book's warning-admonition tone) with a small icon reading "Order now or choose a faster option," recalculated live as the slider moves. Clicking any band opens an infobox with a one-sentence description of that sourcing option, matched to the vendor comparison table earlier in the chapter.
Implementation: vis-timeline DataSet of four range items with start fixed at "today" and end computed from each option's lead time in days. Recompute the "Unit Start Date" reference line's Date object whenever the slider changes, and recheck each band's end date against it to toggle the warning style.
Designing a Classroom Kit¶
Not every part on a BOM behaves the same way after a student finishes a project, and planning a kit means sorting parts along the reusable versus consumable distinction: reusable components (a Pico, a breadboard, a distance sensor) can be collected back, cleaned, and issued to a different student next term, while consumable components (a coin-cell battery, solder, double-sided tape) are used up and must be repurchased for every new build. A kit's real recurring cost per term is driven almost entirely by its consumable items, since reusable items are effectively a one-time investment.
Once a kit's contents are settled, a kit checklist — a fixed, itemized list of exactly what belongs in one complete kit, used to verify a kit is complete both before it's issued and after it's returned — keeps kits consistent across dozens of copies and makes a missing part obvious immediately, rather than discovered mid-lesson when a student can't find a jumper wire.
Berry's Key Insight
Reusable components are a one-time investment; consumables are the number that actually shows up in next year's budget request. Track consumables like a recurring subscription rather than a one-time purchase, and your term-over-term budgeting gets far more predictable.
The list below sorts a typical Tier 2 robot-kit BOM into the two categories just defined, showing how a kit checklist would group them.
- Reusable (collect back, reissue next term): Pico W board, robot chassis, motors, wheels, distance sensor, USB cable.
- Consumable (repurchase every term): AA or coin-cell batteries, double-sided mounting tape, zip ties.
- Kit checklist entry example: "Kit #14 — 1x Pico W, 1x chassis, 2x motor, 2x wheel, 1x distance sensor, 1x USB cable, 4x AA battery, checked out to: _, condition on return: _."
Organizing and Storing Kits at Scale¶
Twenty-five individual kits create a physical-space problem a single project never does, which is where classroom kit organization comes in: a consistent system for how kits are packaged, labeled, and physically arranged so a teacher can distribute and collect them in minutes rather than a full class period. Most successful setups pair that system with storage and inventory: a running record of exactly how many of each component exist, where they're stored, and how many are currently checked out, so a shortage of jumper wires is caught during summer prep rather than during a Tuesday lab.
Not every component needs to live inside an individual kit, however. A shared component bin holds commonly needed items — extra jumper wires, batteries, a shared box of small screwdrivers — in one central location that any station can draw from, which is usually cheaper and more space-efficient than stocking every single kit with its own full spare set of low-cost, high-turnover items.
Equipment Lifecycle: Loaners, Damage, and Repair¶
Reusable components eventually need rules for how they move in and out of a program, especially when equipment travels home with a student. A loaner equipment policy is a written set of rules for lending reusable hardware outside of class time — who's eligible, how long equipment can be out, and what happens if it isn't returned — that protects both the program's inventory and the borrowing student by making expectations explicit up front rather than assumed after something goes wrong.
Equipment used by dozens of students across a term will eventually break, and a damage and repair plan decides in advance how that gets handled: a stock of spare parts, a simple triage process for repairable versus replace, and a clear policy on whether a student is responsible for accidental damage. Planning this before the first broken wire happens keeps a single dropped breadboard from turning into a stalled lesson while someone improvises a decision on the spot.
You've Got This!
A snapped jumper wire or a bent GPIO pin isn't a crisis — it's the same "training montage" moment from Chapter 1, just happening to your equipment instead of a student's code. A repair plan turns "something broke" from an emergency into a two-minute swap.
Before the next section, it's worth seeing that triage decision as a repeatable process rather than a case-by-case judgment call each time something breaks.
Diagram: Damage and Repair Triage Guide¶
Run the Damage and Repair Triage Guide MicroSim fullscreen
Damage and Repair Triage Guide (clickable Mermaid diagram)
Type: mermaid-diagram
sim-id: damage-repair-triage-guide
Library: Mermaid
Status: Specified
Learning objective: Students will apply (Bloom L3: Apply) a damage-and-repair triage process to decide whether a damaged component should be repaired, replaced from spares, or removed from the kit rotation.
Canvas: responsive Mermaid flowchart rendered at container width, using Mermaid's default responsive SVG scaling.
Layout: a top-down Mermaid flowchart starting at "Component reported damaged," branching to "Is it safe to power on?" — No leads to "Remove from service immediately, tag for review"; Yes leads to "Is a spare in the shared bin?" which splits into "Yes: swap immediately, log old unit for repair" and "No: is it repairable with basic tools?" which splits again into "Yes: repair and return to inventory" and "No: retire and add to next order's BOM."
Interaction: every node has a click directive opening a short definition/tip in an infobox beneath the diagram — for example, clicking "Is it safe to power on?" shows a one-sentence electrical-safety reminder tied to the Electrical Safety concept defined later in this chapter, and clicking "Remove from service immediately" shows a reminder to log the incident on the kit checklist. A "Reset" link below the diagram clears any open infobox.
Implementation: Mermaid flowchart TD syntax with a click NodeId "javascript:showInfobox('NodeId')" directive on every node, paired with a small JavaScript object mapping node IDs to infobox text, satisfying the requirement that every node in a Mermaid diagram be interactive rather than a static image.
Funding Sources: Grants and Donated Hardware¶
A realistic budget also needs a realistic funding plan, and most programs draw on more than one source. Grant funding is money awarded by an organization — a school district, a foundation, a corporate STEM education program — specifically to support a defined educational purpose, usually requiring an application describing the project's goals and expected outcomes rather than being available simply on request. Donor-sourced hardware is equipment obtained through donation rather than direct purchase — a local business's retired laptops repurposed as lab computers, or a parent's professional network donating a batch of boards — which can meaningfully lower cost per student but usually arrives without a warranty and on a donor's own timeline, not a class's.
Worth Knowing
Donated hardware is a gift, not a guarantee — test every donated board before it goes anywhere near a lesson plan, since a "should still work" unit that fails mid-class costs more instructional time than it saved in budget.
The table below compares these two funding sources across the factors that matter most when deciding which to pursue first.
| Factor | Grant Funding | Donor-Sourced Hardware |
|---|---|---|
| Predictability | High once awarded, but application takes time | Low — arrives on the donor's schedule |
| Paperwork | Application and usually a report on outcomes | Minimal, sometimes a thank-you acknowledgment |
| Equipment condition | New, purchased to spec | Variable, should be tested before use |
| Best used for | Planned, budgeted units with a lead time to apply | Filling gaps or expanding beyond the core budget |
Safety Guidelines for Electrical and Battery-Powered Projects¶
Every hardware tier in this book, from a breadboard to a Pi 5, is genuinely safe for classroom use when handled correctly — but "handled correctly" needs to be taught explicitly, not assumed. Safety guidelines are the specific, written rules a program follows to prevent injury or equipment damage during hands-on electronics work, covering everything from tool handling to what to do if smoke or an unusual smell appears. Two categories deserve their own explicit rules in every Learning STEM with Raspberry Pi Hardware classroom.
Electrical safety covers the practices that prevent shock, short circuits, and component damage: always disconnect power before rewiring a breadboard, never bridge power and ground pins directly, and inspect wiring for exposed conductors before applying power. Voltages in this book's projects are low — 5 volts or less on Pico and Pi GPIO pins — but a short circuit can still damage a board or, in the worst case, get hot enough to be a burn hazard.
Battery safety covers the additional rules specific to battery-powered projects: correct polarity (positive to positive, negative to negative) every single time, never puncturing or crushing a battery, and immediate removal from service of any battery that's swollen, leaking, or unusually hot to the touch. Lithium-based batteries, increasingly common in portable robot kits, are more sensitive to damage and incorrect handling than the alkaline batteries many students have handled before.
Berry's Serious Warning
Safety rules in this section are not optional classroom flavor — they are the baseline for running electronics labs responsibly. Walk every student through electrical and battery safety before the first kit is opened, post the rules where students can see them, and know in advance what to do if a battery overheats or a board smells hot. Take this seriously every single time, not just the first week.
Running the Lab: Time, Space, and Group Size¶
With budget, kits, and safety in place, the remaining decisions are about how a lab period actually runs. Classroom time management for a hands-on lab means budgeting minutes for setup, instruction, hands-on build time, troubleshooting, and cleanup separately, rather than assuming "build the project" will simply fill whatever time remains — a robot-wiring lesson that looks like a 40-minute build can easily become a 60-minute lesson once setup and cleanup are counted honestly.
Lab station setup is the physical arrangement of a classroom into defined work areas, each stocked with exactly what a group needs for the day's task, with tool and material placement consistent from session to session so students spend their time building instead of searching for a screwdriver. Group size planning decides how many students share each kit and workstation, balancing available equipment against how much hands-on time each individual student actually gets — pairs tend to keep both students engaged with a single kit, while groups of four or more risk one student doing all the wiring while the others watch.
Berry's Tip
If you only have budget for half the kits a full class needs, pairs beat quartets almost every time. Two sets of hands on one breadboard still means everyone wires something; four sets of hands usually means two students just watch.
Before the next diagram, note that lab station setup and group size planning are really two views of the same room — one is about where things sit, the other is about who stands where — which is exactly what the layout below lets you explore together.
Diagram: Lab Station Layout and Group Size Planner¶
Run the Lab Station Layout and Group Size Planner MicroSim fullscreen
Lab Station Layout and Group Size Planner (interactive infographic)
Type: interactive-infographic
sim-id: lab-station-layout-group-size-planner
Library: p5.js
Status: Specified
Learning objective: Students will apply (Bloom L3: Apply) group size and station layout decisions to configure a classroom lab for a given number of students and available kits.
Canvas: 700x480px default, responsive — recompute the room grid from windowWidth/windowHeight fractions on windowResized().
Layout: a top-down floor-plan view showing a grid of lab station rectangles, a shared component bin icon in a fixed central or perimeter location, and a teacher-desk icon. Each station rectangle shows a small count of student icons standing at it, matching the current group size setting.
Controls: a createSlider() labeled "Number of Students" (range 8-40, default 24); a createSlider() labeled "Number of Available Kits" (range 4-20, default 10); a createSelect() dropdown labeled "Group Size" with options 1, 2, 3, 4 (default 2).
Interaction: the layout recalculates the number of stations needed as ceil(numStudents / groupSize) and compares it to available kits; if stations needed exceeds available kits, affected stations are drawn in a warning color with a label "Kit shortage — increase group size or add kits." Clicking any station opens an infobox listing that station's assigned group size and a reminder that the shared component bin (drawn as a distinct icon) supplies items common to every station rather than duplicated in each kit. Clicking the shared-bin icon shows the example bin contents list from earlier in the chapter.
Implementation: p5.js, station positions computed as a grid laid out from numStations using sqrt() to pick a roughly square row/column count, redrawn fully each frame from current slider/dropdown values. Hit-testing via rectangular bounds per station icon.
Meeting Every Learner: Differentiation and Assessment¶
Budget and logistics only matter in service of actual learning, and this book's dual-track design — its outcomes are explicitly separated into [Student] and [Educator] tags — assumes classrooms are never made up of identical learners. Differentiated instruction is the practice of adjusting a lesson's pace, scaffolding, or challenge level for different students within the same class period — offering a pre-wired kit to a student who's new to breadboards while a more experienced student tackles an open-ended extension of the same project, without changing the underlying learning objective.
Judging whether a project met its learning objective, fairly and consistently across dozens of students, is the job of an assessment rubric: a scoring guide that breaks a project down into specific, gradable criteria — did the circuit work, was the code readable, could the student explain their debugging process — rather than a single subjective pass/fail judgment. A well-built rubric also gives differentiated instruction something concrete to differentiate around, since the same rubric can score a basic build and an extended one, just against different criteria weights.
Now that both terms are defined, the table below shows how one rubric can score two different versions of the same NeoPixel project, reinforcing how differentiation and assessment work together.
| Criterion | Basic Build (novice) | Extended Build (experienced) |
|---|---|---|
| Circuit wired correctly | Required, teacher-checked | Required, self-verified |
| Code produces a working pattern | One static color pattern | An original, animated pattern |
| Debugging process explained | Can describe what was tried | Can explain root cause of a specific bug |
| Extension attempted | Not required | Required (e.g., reacts to a sensor) |
Bringing It Together¶
None of the projects earlier in this book happen at classroom scale without the planning this chapter covers. A budget without a sourcing plan stalls at the shortage. A sourcing plan without kit organization turns into a supply closet nobody can find anything in. And even a perfectly organized kit collection fails a student if safety isn't taught explicitly or if the lesson doesn't flex for the range of learners actually in the room. Every one of the twenty-six ideas in this chapter exists to answer one practical question: how does a great single-student project become a great unit for an entire class?
You Unlocked a Superpower!
That's berry impressive planning work — you now have a real budget, a sourcing strategy, a storage system, and a safety plan, not just a project idea. That's the superpower that turns one great lesson into a program students remember. STEM is our superpower, for every learner in the room. Let's build something — see you in Chapter 20 for the capstone!