Everything technical has been decided and written down. These are the questions only you can answer — none of them require any technical knowledge, and most take a minute.
Question 1 is the one that matters most. If the answer is the recommended option, the programme can launch with the ten sessions you have already written, and the four unfinished ones become additions you publish later rather than a wall in front of launch.
Where we have a recommendation, it is marked and the reasoning given in one line. Every recommendation can be overruled — nothing has been built in a way that assumes your answer.
Answering these in one working session unblocks the design and engineering work. None of them requires you to write anything — they are decisions, not drafting.
Should the programme be a 10-session core plus a browse-anytime library of 5 extra topics, or a single 15-day sequence as your July content document laid it out?
Core of 10, then a library. Launch uses only the sessions already written. The five unfinished topics arrive later as additions. The awkward "14-day vs 15-day" wording problem disappears entirely, because neither number gets used.
One 15-day sequence. Launch waits until all fifteen sessions are written, and you must pick one number — 14 or 15 — and apply it consistently across all marketing and welcome copy.
If you choose A, also tell us where the closing session belongs — the reflection letter, future plan and feedback screen. Finale of the core, or shown whenever someone finishes?
Your Final Developer Specification chooses Option B: 15 modules, presented in order, no core/extension split, no calendar lock. Module 15 ("Moving Forward") is the finale of that sequence, reached on completion — not a separate always-available closing screen.
Because that same document also supplies full screen-by-screen copy for Sessions 11–15, the usual cost of Option B — launch waiting on four unwritten modules — no longer applies. The build is unblocked either way.
Please confirm: sessions unlock in order as each one is completed. Someone keen can do several in a day. The app suggests spacing them out but never blocks. Nothing is ever labelled "Locked". Missing days carries no penalty.
This replaces the original one-per-calendar-day design. It is already built — this is purely a yes or no.
Confirmed yes. Your spec states this explicitly — recommended pace 2–4 modules/week, no calendar locking, no mandatory waiting periods, missed days carry no penalty.
Confirm: once someone finishes, their home screen becomes their Toolkit first — along with the quick-help entry, emergency tools, optional light check-ins, and the extras library.
One extra call: should people be able to redo a whole session from scratch, writing fresh answers? Or is revisiting what they wrote, plus re-running any exercise, enough?
We have built the second. The first can be switched on later if you want it.
Partially answered. Your spec confirms the Toolkit stays available after the programme ends and that users can revisit completed modules and rerun exercises — matching what's built. It doesn't say whether a full from-scratch redo (fresh answers, not just a rerun) should also be offered — that half of the question is still open.
Three parts, in this order:
We previously said this text needed writing from scratch. That was our error, from reading your document second-hand. Your notes say "keep your existing text" / "pidä nykyinen tekstisi sellaisenaan" — you're telling us not to overwrite writing you've already done. Sorry for the alarm.
So this is now just: which file is it in? Drive version history on the content document is also worth a glance, in case an earlier revision still holds it.
One genuine gap remains here: session 14's eight Recovery Wheel icons really were corrupted in the export and need re-supplying.
Resolved — and further than we asked. Your Final Developer Specification doesn't just point us at a file: it contains the actual screen-by-screen text for Sessions 11–15 directly. Titles confirmed as the July set: 12 Self-Compassion Under Stress, 13 Understanding Your Emotional Needs, 14 Balance Your Battery, 15 Moving Forward. We'll build from this document. The Recovery Wheel icon gap (Q6) is the one thing it doesn't close.
First: is the tool list six or seven — is "Progressive relaxation" in or out?
Then the remaining scripts. The breathing work has already covered Breathing reset and Grounding, so what's left is the thought-dump journal introduction, the desk stretch, and the safe-place exercise — plus progressive relaxation only if you keep it.
These tools are visible from day one, and the "help me right now" entry cannot switch on until they exist. This is the highest-value short writing task in the whole project.
Six tools confirmed — but not the six we asked about. Your spec keeps Grounding (now "Ground Me"), Breathing reset (now "Slow My Breathing") and Safe place (now "Find Safety"), and renames Progressive Relaxation to "Tense & Release" rather than dropping it. But Body scan, the Quick thought-dump journal and the Desk-based stretch routine aren't in your list at all — you've replaced them with two new tools, "Cool Down" and "Pause, Name & Choose."
All six have full scripts, so there's nothing left unwritten. Worth a quick confirm that swapping out those three specific tools — rather than just writing the scripts we asked for — was a deliberate redesign and not an oversight.
The eight Recovery Wheel category icons were corrupted in the export. Confirm the intended meaning of each — our best guesses are Rest 🌿, Connection 🤝, Movement 🏃, Nature 🌳, Creativity 🎨, Learning 🧠, Joy & Play 🎲, Purpose ✨.
Then tell design what the end-of-programme celebration should look like.
We will render these as properly drawn icons, not emoji — emoji look different on every device and read poorly for screen-reader users.
Category meanings confirmed — your spec uses the same eight areas, in the same order (Rest, Connection, Movement, Nature, Creativity, Learning, Joy & Play, Purpose), matching our best-guess reconstruction. Still needed: actual icon artwork (we'll draw these properly, not emoji) and direction on what the completion celebration should look like — your spec gives the completion copy but no visual treatment.
Sessions 1 and 2 currently end with the identical reflection question — "Where did you notice stress in your body today?" Intentional, or should one change?
Then, for each session, pick how it ends: do a tiny action right now / save today's tool / a "when X happens, I'll Y" intention / set a reminder / just an insight.
Reminders should be the exception, not the default — almost every session currently ends with one, which is how notification fatigue starts. One pass over the ten-session list.
Not settled by the new spec — worth a direct answer. Sessions 1 and 2 in your Final Developer Specification still use the identical wording, word for word: "Where did you notice stress in your body today?" That could mean you've reviewed it and kept it on purpose, or that it simply wasn't front-of-mind while assembling a 15-module document. Either is fine — we just need to know which, since it changes whether we treat it as a bug to fix.
On the ending-type question: most modules (1–9, 14) give both "Add to Toolkit" and "Set a reminder" as parallel optional actions, rather than one of the five ending types each — modules 10–13 drop the reminder option, so it does taper off, but reminders are still the majority pattern. Worth a quick look if the notification-fatigue concern above still matters to you.
These matter, but none of them holds up engineering. Days rather than hours is fine.
Version 1 ships with written guidance and an on-screen pacer, no recorded audio. It's fully usable that way, and the silent-office design always made audio optional.
Your decision is only whether you ever want recorded voice — and if so, whose voice, which languages, and when. Adding it later needs no engineering work.
The pitch materials promise daily energy, stress and mood tracking — but no session actually asks about mood.
Either add a mood question to the daily check-in (costs nothing — just say so), or drop "mood" from the pitch. Which?
Finland first, English-speaking first, or both?
This decides which crisis helplines ship by default, which language the missing text gets written in first, and where legal review happens. The product is built translation-ready either way.
The three price tiers (€4–8 / €15–30 / €120–300 per user per month) have never been tested with an actual buyer. Recommendation: validate the first tier in the pilot and treat the others as indicative.
Separately — your two decks define Tier 2 differently. One says message a real therapist; the other says smarter automatic personalisation. Those are different costs, different value stories and different prices. Settle the ladder before quoting anyone.
Neither of these blocks the build. Tier 1 is identical under both readings, and Tier 1 is the whole first version.
The buyer wants numbers; the product refuses clinical questionnaires. The recommendation stands: use only the product's own simple ratings — stress, energy, confidence, and the feedback screen. No PHQ-9-style instruments.
Adding standard screening instruments would contradict the product's own promise not to diagnose, and would change what it is in regulatory terms. Confirm you're comfortable selling on that basis.
The safety machinery is built: the always-visible "Need urgent help?" card, the onboarding disclaimer, the supportive check-in prompt, and a fully private on-device word-check that can surface the help card if someone types crisis language.
Two decisions: (i) the wording of the disclaimer, the help card and the supportive prompt — your voice, reviewed clinically. (ii) Whether the word-check on things people write is on or off at launch.
You say: "the app itself, privately on your device, may show you help resources if it spots concerning words."
You say: "no one and nothing looks at what you write."
It costs nothing either way and never sends anything anywhere. The honest difference is only what you can promise.
Part (i) drafted. Your spec includes full wording for the safety screen — "Need support right now?", the emergency/urgent-care disclaimer, and a persistent "Need urgent help?" action. We'll use this in place of the placeholder copy. Part (ii) — whether the private on-device word-check is on or off at launch — isn't addressed and still needs your call.
Nothing to decide — this is a question to ask the pilot customer rather than answer in advance.
The metrics, privacy gates and configuration are settled. What's still wanted from you and design is how it should look, and the format of the pilot report you'll hand the HR buyer.
Check-ins now use tap-to-select buttons rather than sliders. We'll test 5 buttons against 10 with real people before the pilot. Until then it's 10, which keeps every existing safety threshold valid as it stands.
If the test favours 5, the safety thresholds get clinically re-derived — the system physically will not allow them to be halved arithmetically.
Scale confirmed — your spec uses 1–10 throughout, matching the untested default. One wording check: every check-in in your spec is labelled "Interactive sliders." We moved this control to tap-to-select buttons for accessibility (drag sliders work poorly with screen readers and keyboard navigation). Assuming that's just a descriptive turn of phrase rather than a request to bring sliders back — flag it if not.
(i) Session 1 currently teaches Box Breathing. It holds the breath, carries cautions for pregnancy and heart and lung conditions, and is the weakest-evidenced option in the library.
Teach Longer-Exhale Breathing instead — no holds, safest option, and the same exercise the app recommends everywhere else. Box Breathing stays available for people who like it.
Keep Box Breathing as the Day 1 exercise.
(ii) Library size: launch with three — longer-exhale, grounded, box — which means only one new script to write, then add the other two soon after. Confirm this phasing or change it.
(iii) Write the one-line question shown after an exercise, in your words. Ours: "How do you feel now?" — steadier / about the same / that felt uncomfortable.
One heads-up rather than a question: at launch the app recommends by evidence and your favourites. "Because this worked for you before" suggestions come after the pilot. If you want them at launch, say so — it's a small change.
Answered — you've picked the alternative, not the recommendation. Session 1 in your spec keeps Box Breathing exactly as before (4-in / 4-hold / 4-out / 4-pause), with its own dizziness safety note. That reads as a considered choice, so we'll build it as specified rather than push back again — say the word if that's wrong.
On (ii): library size is effectively settled too — your Emergency Tools now include a longer-exhale exercise ("Slow My Breathing") and grounding ("Ground Me") alongside Box Breathing, so all three exist rather than one still to write.
On (iii): your spec's own post-exercise wording — "How do you feel now?" / Better / About the same / Worse — replaces our placeholder; we'll use yours.
The research says: some people find it helps a lot, most a little, and on average it is hard to distinguish from simply taking five minutes off.
The app already frames it as "try it for a couple of weeks and see if it works for you". The question is how plainly to say the rest — quietly honest, or openly honest as a trust differentiator?
Worth knowing: no competitor does this. Evidence labelling across the market runs from vague to inflated, and none of them admits when evidence is preliminary. Draft two or three framings and we'll test them internally.
Not yours to answer alone — but yours to commission. The first one has the longest lead time of anything in the project and nobody is currently working on it.
A formal decision is needed: Minimente as the data controller for employee wellbeing data, with the employer being neither controller nor processor of it.
This is the recommendation because the alternative gives the employer arguable access rights to employee health data — which would destroy the product's central promise. Then the privacy impact assessment must be completed before pilot launch. Everything engineering needs to supply is ready and waiting.
A clinician needs to review and sign off the crisis and self-harm term list used by the on-device matcher, and check the search vocabulary for clinical adjacency.
Both are plain content files — the format is fixed, only the words are needed. Blocks shipping search, not building it.
The rules are built and ship with placeholder values that the release system refuses to publish until marked clinically reviewed. A clinician confirms or replaces the numbers; the mechanism and destinations are already settled.
Only applies if the user test picks the 5-point scale. If 10 wins, there is nothing to do.
Confirm the refusal to build routes for "acute anxiety" or "panic". Both would require clinical labels the product forbids, and breathing during panic is contested-to-counterproductive in the current evidence.
The nearest available state — "It's all too much" — routes to grounding plus help resources. Confirm this, or propose a different non-clinical framing. Please don't resolve it by adding a clinical label.
Minni's new spec's Emergency Tools menu includes "I feel panicky or highly activated → Slow My Breathing" as a direct menu option — routing straight to a breathing exercise on a near-clinical word. That sits in tension with the caution above: breathing during panic is contested-to-counterproductive in the current evidence, and clinical-sounding labels were meant to be avoided here specifically. Worth resolving explicitly with her rather than shipping both positions at once.
One pass over the five breathing protocols and the mapped situations, confirming the evidence grades — several sources were verified only at abstract level.
This should happen before Session 1's exercise is changed on the strength of that research. It folds into the same sitting as C1.
1. Answer Q1 — it determines whether launch waits for unwritten content.
2. Write the three remaining quick-help scripts (Q5) — they gate the "help me right now" feature.
3. Commission the legal and clinical reviews (L1, C1–C5) — they are slow, they block launch, and nobody has started them.
PRD_v4.md, PRD_v4_Addendum_Breathing.md and PRD_v4_Technical_Decisions.md. The underlying research sits in research/.