When I first started using the Gene Café CBR-301 app, one thing stood out immediately.
The app gives access to roast data.
That matters. Not every coffee roaster app makes exportable data feel accessible or useful. The Gene Café JSON export contains a lot of what I want to see after a roast: the reported temperature over time, fan behaviour, motor/stirring behaviour, roast settings, weight entries if I added them, and enough timing data to start comparing one roast with another.
But there was a gap.
The app records the data, but it does not really explain the data.
That gap is where the Gene Café JSON Roast Report beta started.
The first design idea: make the roast readable
The first goal was not prediction.
It was translation.
A Gene Café JSON file is useful, but it is not pleasant to read directly. The first version of the tool simply tried to turn that export into a clear report:
- what roast file was uploaded
- what coffee and batch size were recorded
- what the app-reported temperature curve looked like
- when the roast crossed key reported ET milestones
- when fan changes were detected
- whether weight loss was available
- what the broad roast outcome might suggest
From the beginning, the language had to stay careful.
The temperature shown by the Gene Café app is not bean temperature. It is the temperature reported by the machine/app system. That makes it useful for comparison, but it does not turn the CBR-301 into a precision profiling machine.
So the early design rule became:
Show the data first. Interpret gently after.
The second design idea: evidence before advice
A lot of roasting tools are tempting because they promise answers.
I wanted this tool to do something quieter.
It should help the user ask better questions:
- How fast did this roast move?
- Was this a cold start or warm start?
- When did the fan intervene?
- Did the graph match the final weight loss?
- Does this look similar to another roast I have done?
- Does the cup agree with what the report suggests?
That led to the extracted-data table becoming an important part of the report.
The report does not hide the numbers behind a conclusion. It shows the values it read from the file, then gives cautious notes. If the extraction is wrong, the interpretation will be wrong, so the user should be able to check the raw interpreted values easily.
That is also why the wording uses phrases such as:
- appears to
- may suggest
- useful clue
- comparison only
- cup result decides
The tool is not there to overrule taste. It is there to make the roast easier to understand.
The third design idea: privacy first
As soon as contribution became possible, privacy had to be designed in from the start.
The app can analyse a JSON file without automatically donating it.
Uploading a file for analysis is not the same as contributing data.
The contribution step is optional and separate. The raw JSON is not kept. Photos, base64 image data, notes, comments, device identifiers, and personal metadata are not stored as part of the contribution dataset.
The useful data is the roast-behaviour data:
- timings
- reported temperature points
- batch size
- target temperature
- start temperature
- weight loss if available
- fan and motor/stirring events
- crack-marker flags if present
The design idea here is simple:
Collect only what may help the roast model. Avoid everything else.
That keeps the project aligned with the purpose of the tool: learning how the Gene Café behaves across real roasts, not gathering personal data.
The fourth design idea: validation before contribution
Once contribution existed, the next issue was data quality.
A valid JSON file is not automatically a valid Gene Café roast export.
So the tool gained client-side validation before deeper analysis or contribution. It checks that the file looks like a real roast export: a usable data[] array, enough rows, time and temperature fields, plausible temperature movement, and expected Gene Café-style metadata.
This is deliberately defensive.
The tool should be permissive about optional roast details, because users will not always record every field. But it should reject files that are clearly not Gene Café roast exports.
The design insight was:
Be forgiving about incomplete roast notes, but strict about the file shape.
The fifth design idea: the graph needed supporting context
The reported ET graph is useful, but on its own it can still invite over-reading.
So the report grew supporting visuals:
- reported ET orientation bands
- a rough visual colour-gradient cue
- fan and motor/stirring timeline
- ET30, a 30-second reported temperature-change view
Each of these needed careful caveats.
The colour-gradient cue is not actual bean colour. It is only a rough visual orientation aid based on the reported ET range. ET30 is not professional bean-temperature Rate of Rise. It is a reported-temperature-change learning aid.
The design aim was to make the report easier to read without pretending the data is more powerful than it is.
That became another working rule:
Add visual help, but label it honestly.
The sixth design idea: export belongs to the user
Once the report became useful, it made sense to let users keep their own data.
The tool now allows local exports:
- summary CSV
- telemetry CSV
- report-data JSON
This is important for two reasons.
First, it gives the user ownership of their analysis. They can save the extracted data, inspect it, or use it elsewhere.
Second, it creates a cleaner path for future comparison features. A saved report-data JSON can be used again without needing the original raw Gene Café export.
The browser now tries to use a native Save As picker where supported. If the browser does not support that, it falls back to normal download behaviour.
The design idea was:
Do not trap the learning inside the page. Let the user take the useful data away.
The seventh design idea: one fixed reference is not enough
The first comparison logic used an early reference set.
That was useful, but also limited.
A warm-start roast can look fast against a cold-start reference simply because the machine was already warm. That does not necessarily mean the roast is unusual. It may be normal for its context.
So the tool gained a cautious similarity-based comparison.
Instead of only asking:
How does this roast compare with one early cold-start reference?
it can begin asking:
How does this roast compare with similar contributed records?
That is a major design shift.
It moves the tool away from one universal reference and toward comparing like with like: similar batch size, similar target temperature, similar start state, and available milestone timings.
This is still early and provisional, but it is the future direction.
The “So what?” box was added because this needs explanation. The value is not just that the table says “faster” or “slower.” The value is that it helps separate machine pace from roast context.
A roast may look fast against the wrong reference, but normal against similar records.
That matters if this ever becomes a sensible TRT range finder.
The eighth design idea: compare two of your own roasts
The most useful next step was not to jump straight to prediction.
It was to let users compare their own roasts.
That is now part of the public beta.
After analysing one roast, the user can choose Compare with another JSON and upload a second Gene Café export or a saved report-data JSON.
The report then shows:
- Roast A and Roast B summary cards
- what changed
- milestone timing differences
- fan 2→3 timing
- weight loss difference
- batch size difference
- start-temperature difference
- total logged time difference
- reported ET overlay
- ET30 comparison
- stacked fan/motor comparison
- a “So what?” explanation
This is where the tool starts to feel genuinely useful.
Two roasts can have similar curves but different weight loss. Or very different starts but similar top-band behaviour. Or similar total time but very different early pace.
The comparison feature helps make those differences visible.
The design rule here is:
Compare what changed before deciding what it means.
What the tool is now
The current public beta is still not a prediction engine.
It is not official Gene Café guidance. It does not measure bean temperature. It does not score roast quality. It does not tell the user what they must do next.
What it does is more modest, and I think more useful:
- turns a Gene Café JSON export into a readable roast report
- visualises reported ET, fan/motor behaviour, and ET30
- extracts key roast data into a checkable table
- gives cautious learning notes
- supports optional anonymous contribution of extracted roast data
- lets users export their own report data
- lets users compare two of their own roasts
- saves the combined report as PDF if they want a record
For a project built around learning one roast at a time, that feels like the right direction.
The bigger direction
The longer-term idea is still the Range Finder.
But the path to that cannot be magic prediction.
The path has to be:
- understand one roast
- compare it with another roast
- compare it with similar records
- understand machine pace and context
- only then suggest cautious starting ranges
That is why the app has evolved this way.
It started as a report.
It became a comparison tool.
If enough good data and feedback arrive, it may eventually become a careful starting-range assistant.
But the core principle stays the same:
Roast, weigh, taste, compare, and learn.
No fake precision. No drama. One roast at a time.