Invention, Intellectual Property and Income

This week is about what happens to ORDER after Fab Academy. ORDER is my final project, an ESP32 touchscreen device that sits on a restaurant table so guests can browse the menu and place their order over WiFi, all inside a 3D printed enclosure. Here I plan how I will share it, who is allowed to use it, whether it could grow into a small product, and I keep tracking where the build stands.

My dissemination plan for ORDER

I want other people to be able to learn from ORDER and rebuild their own, so I will share everything openly. The plan has clear parts so nothing is left out.

1. Documentation: the full story of ORDER lives on my Fab Academy page, the design choices, the electronics, the firmware, and the photos of every stage.
2. Design and source files: I will publish the enclosure STL and CAD files, the schematic and board files, and the ESP32 firmware in a public Git repository so the files can be downloaded and changed.
3. Build guide: I will write a short step by step guide that takes a reader from a bare ESP32 and a screen to a working ORDER device, including the bill of materials, the wiring, how to flash the firmware, and how to print the case.
4. Where I will post it: I will link the repository from my Fab Academy page, share it with the Fab Lab Rwanda community, and post about it on the Fab Academy network and online maker channels so restaurants and students can find it.

The licence I chose and why

ORDER has two kinds of work in it, written documentation with design files, and code. I picked a licence for each.

• Documentation and design files: Creative Commons Attribution ShareAlike. This lets anyone read, print, and remix the enclosure and the build guide as long as they credit me and keep sharing under the same terms.
• Firmware and code: the MIT licence. It is short and easy to understand, and it lets people use the ORDER firmware in their own projects, even commercial ones, as long as they keep the credit.

I chose open licences because the whole point of ORDER is to be copied and improved by other labs and small restaurants. I picked Creative Commons for the documents and MIT for the code because they are the licences most makers already recognise, so nobody has to stop and figure out what they are allowed to do. Asking only for credit keeps it friendly while still tying the work back to me.

Future opportunities, and how to make them probable

Right now ORDER is a working prototype on one table. There is a real chance to grow it, and each step has something concrete I can do to make it more likely instead of just hoping.

• Make it cheaper and cleaner: shrink the board, tidy the wiring, and refine the printed case so a unit is affordable to repeat. I make this probable by sourcing parts locally and pricing a full bill of materials.
• Small batch: build a handful of ORDER units instead of one. I make this probable by reusing the same firmware and the same print so each extra unit is mostly copy and assemble.
• User testing in a real restaurant: put ORDER on real tables during a real service and watch how guests and staff use it. I make this probable by partnering with one local restaurant in Kigali that is willing to try a few tables.
• Income and business model: the likely model is selling ORDER units to restaurants plus a small monthly fee for the menu software that runs behind them, or renting the devices per table. I make this probable by testing whether a restaurant would pay after they have used it, not before.

My short, medium, and long term view stays simple. Short term I tidy the design, write the guide, and share it. Medium term I build a small batch and test it in one restaurant. Long term, if real demand shows up, I look at producing more units and the paid menu service.

Progress, what is done and what remains

Here is an honest status of where ORDER stands today.

• Done: the ESP32 and touchscreen wiring, reading touches and drawing the menu on screen, the WiFi connection, sending an order from the table over the network, and a first 3D printed enclosure.
• Still to do: the final enclosure with a clean cut out for the screen, full integration of firmware and case on one tidy unit, and a test across a full service.

What is working and what is not

• Working well: the touchscreen draws the menu reliably, taps register cleanly, and an order sent over WiFi arrives at the receiving end without dropping.
• Not working yet: the screen cut out in the enclosure is slightly tight, and the device still depends on a steady WiFi signal, so a weak connection in a busy room is not yet handled gracefully.

Questions I still need to resolve

• How should ORDER behave when the WiFi drops mid order, does it queue the order and resend, or warn the guest?
• How do orders from several tables reach the kitchen cleanly, one small server, or each device talking straight to a screen?
• Will the printed enclosure hold up to daily restaurant handling, spills, and cleaning?
• Would a restaurant actually pay for ORDER, and is it a one off sale or a monthly service?

Timeline, what happens when

This is my plan for the time left before the presentation, kept short so I can update it as things move.

1. Week 1: finish the enclosure with a clean screen cut out and reprint it.
2. Week 2: full integration, firmware and case together as one tidy ORDER unit, and handle the WiFi drop case.
3. Week 3: publish the repository, write the build guide, and apply the licences.
4. Week 4: test ORDER across a full mock service, fix what breaks, and prepare the final presentation.

What I learned

This week made me think past the deadline and treat ORDER as something that could outlive the course. Choosing a Creative Commons licence for the documents and MIT for the code forced me to decide exactly how I want ORDER used, and writing the dissemination plan showed me that documentation is not just for the grade, it is what lets someone else rebuild ORDER after me. Sketching the income model also taught me that the question is not whether ORDER is clever, it is whether a real restaurant would pay for it, and the only honest way to find out is to put it on a table and watch. Being clear about what is done, what is not, and what I still need to ask made the remaining work feel manageable.

Downloadable files