Chapter 9 — Where This Goes Next: Making It Usable for Everyone
Think of it like this: right now, using Dreamento is like being handed a real car engine and told to build the rest of the car around it yourself — install Anaconda, pick an environment, edit config files, learn a GUI full of scientific controls. That's completely reasonable for a researcher. It's magic — in the unhelpful sense — to a citizen scientist who just wants to know how their night went.
This is the design proposal promised back in "Before You Begin": not a finished product, a real, written plan for the next real step — built from everything covered in the eight chapters before this one.
The Problem, Stated Plainly
Dreamento is genuinely powerful and genuinely open — both real strengths. But its interface assumes the person using it already understands EEG, sleep staging, and Python environments. A citizen scientist with a ZMax headband doesn't need that understanding to benefit from the tool. They need a button, a wait, and a simple, honest answer.
The Proposal: Split the System in Two
Separate "hard to build" from "hard to use." The complexity doesn't disappear — it moves to a place only developers ever have to look at.
- A Flutter app — the only thing a citizen ever touches. One codebase, two targets: a simple desktop app (Windows/Mac) and a mobile app (iOS/Android). Record or upload a night's data, tap a button, see friendly results — "You slept 7h 20m. REM: 1h 45m across 4 periods." No config files, no scientific dashboard, no install instructions involving the word "Anaconda."
- A backend data API — where all the real computation happens. The exact pipeline built across this entire course: load the recording the way Chapter 1 did, epoch and stage it the way Chapters 2–4 did, run it through a trained model the way Chapter 6 did. All of it lives on a server, not on the citizen's device.
WHY THE SPLIT ITSELF MATTERS, NOT JUST THE SIMPLICITY
Keeping all computation server-side means a better model — a properly-trained TinySleepNet, eventually something closer to DeepSleepNet or U-Sleep's accuracy — can reach every single user the moment it's deployed, with nobody reinstalling anything. The app stays simple forever; the backend is where all future improvement happens. That's not just a UX choice, it's what makes continuous improvement realistic at all.
Three Decisions, Made Deliberately Narrow for a First Version
Each of these keeps the first version achievable, not a research project pretending to be a product:
- Input: file upload after a recorded night, not live streaming. A citizen records (via Dreamento or the ZMax's own app) and uploads the resulting EDF file afterward. This matches every single lab in this course exactly — the same MNE/EDF pipeline, no new real-time infrastructure, no device-protocol work. Live streaming with real-time stimulation triggers is a real, much bigger future version — deliberately not version one.
- First users: a software-only prototype, not real hardware yet. Build and prove out the whole app-plus-backend pipeline using the same public Sleep-EDF dataset already used in every lab in this course. No ZMax headband required to validate that the architecture itself works end to end. Real hardware and real citizen testers come after the pipeline is proven, not before.
- Backend: a new, separate Python service — not bolted onto what already exists. The existing Firebase Functions (bioresonance) are Node.js, which can't natively run MNE or PyTorch. The existing FastAPI backend serves the public marketing site — a genuinely different concern from EEG inference, and conflating them would make both harder to maintain. A dedicated FastAPI service, deployed on Cloud Run, reuses the exact Python/MNE/PyTorch code already written and verified across Chapters 1–8, and Cloud Run's pay-per-use pricing fits "process one night's recording, then go idle" far better than an always-on server would.
LEFT DELIBERATELY OPEN
One real decision this proposal does not make: whether results reach the citizen fully automatically, or whether a human reviews them first while the model is still young. Fully automatic is faster to build and ships sooner; human review catches real mistakes (the N1/REM confusion from every chapter in this course doesn't go away just because the interface got simpler) but doesn't scale past a handful of early users. That's a genuine trade-off for whoever builds the next version to decide with real usage data in hand, not something to guess at on paper now.
What "Done" Looks Like for This Proposal
Not code. A plan sturdy enough that someone could pick it up and start building the prototype tomorrow: what the app shows, what the API receives and returns, and which three decisions above were made on purpose rather than by accident.
DONE WHEN
You can explain, to someone who has never seen this course, why the computation lives on a server and not in the app, and you can defend all three narrowing decisions above with a real reason each — not just "it's simpler."
That's the whole Dreamento Dev Path, start to finish: raw EEG voltage, through sleep staging, through a real trained CNN+LSTM, through critical reading of the field's real architectures, into a concrete plan for Dreamento's actual code — and now, a real proposal for how this becomes something an ordinary citizen scientist could actually use.