Submitting your Project
Everything you need to know before you submit.
Built something cool? Awesome. Here's what you need to do before we ship you anything.
There are two submission stages:
- Design Submission: before we ship you the kit
- Build Submission: required after you receive and build it
Both are required. You must ship the build, not just the design.
95% of rejections are fixable in under 5 minutes. Read this carefully.
Stuck? Ask in #breadboard.
Stage 1: Design Submission
This is what you submit before we send you anything. It should prove that you've thought your project through and that someone else could understand and replicate it.
The design stage also earns you bread, the currency you spend in the shop. You get 5 bread per hour of approved design work, so the time you put into planning and wiring up your design actually pays off.
Your Design
We're looking for projects that are actually interesting to build and watch. Here's the bar:
- Cool input. Give people a real way to interact with your project. A single push button is not allowed, and one input on its own isn't enough. You must combine several ways for people to control your project: a keypad, a joystick, a rotary encoder, an RFID reader, an IR remote, and the like.
- Cool output. One blinking LED is the floor and won't pass on its own. Combine outputs like a screen, an addressable LED matrix, a motor, a servo, or a stepper. Make it move, display, or react in a way that's fun to watch!
- Cool sensors. Your project should sense multiple aspects from the real world and react to it. Things like motion, distance, weight, orientation, sound, light, temperature are examples of things that can be sensed.
- A real purpose. There should be a clear reason your project exists, and you should be able to say in one sentence why it needs a microcontroller at all. For instance, a puzzle box that releases its servo latch only after you present the right RFID card, type a keypad code, and give it a secret tilt-and-tap, dropping hints on a small screen as you go might be an interesting idea!
- It makes a decision. Your code has to actually think. Reacting to one reading isn't enough, like turning on a light just because it got dark. A real decision weighs more than one thing: it looks at several inputs, remembers what happened before, or acts differently over time. For example, unlock the door only if the right RFID card is tapped and then the correct keypad code is typed in time.
- Unique firmware. The code has to be yours, and it has to do real work. A copied example sketch or tutorial clone doesn't count. "Real work" means at least one of these:
- A state machine: your project has distinct modes (say "idle", "armed", and "alarm") with rules for when it moves between them.
- A control loop: it keeps reading an input and adjusting an output to hit a target, the way a thermostat holds a temperature.
- Cleaning up sensor readings: smoothing or filtering noisy data so it's actually usable (see the Debounce example).
- Non-blocking timing: doing several things at once without
delay()freezing everything (see Blink Without Delay). - Speaking a protocol: talking to a part over I2C, SPI, or serial.
- No AI-assisted coding. Write your own code.
Your README
Your README is people's first impression, so make it a good one. Someone landing on your repo should understand what your project is, what it does, and why it exists without opening a single file. If they have to dig through your code to figure it out, your README isn't doing its job.
At minimum, your README.md needs to cover:
1. What your project is
- A short description of your project. What makes it interesting? What does it do? How does it do what it does?
- How you use it. What is the input? What does the input do? Output? What does it do? What is being sensed? What does the firmware do?
- Why you made it. What did building this achieve?
Be descriptive!
2. Pictures and diagrams
- Photos or screenshots of your project so it's obvious what it is.
- A clear wiring diagram or schematic.
- Anything else that helps someone understand how it fits together.
- If you use the in-site simulator, link it in the README!
3. The files in your repo
Someone else should be able to open your repo and rebuild your project. That means including:
- A BOM (Bill of Materials) listing the parts you used and how many of each. It can live right in your README! If you design in the Breadboard editor, Publish writes this section for you from your schematic, and you can edit the parts list in the publish dialog.
- If you use KiCad or other platforms that support this, your wiring diagram or schematic file.
- Your firmware source code.
- Any libraries or references your project depends on.
- Folders and files with clear, logical names.
Stage 2: Build Submission
Once you receive your kit and build your project, you must submit your build.
Your build submission must include:
- Photos of the finished breadboard circuit, fully assembled
- A demo video showing it actually working
This is where the real reward kicks in. Once you actually build a project, you earn golden bread, which gets you items from the shop for cheaper! The more you build, the more you save.
Things That Will Get You Rejected
- AI-generated code, designs, or writeups
- Copying someone else's project or a guide
- Missing files from the checklist above