What we found

Four separate reviews ran over your material. This gathers everything they found into one place so none of the work is lost.

Some of it is good news — your session structure held up under scrutiny from four independent sources, and one recommendation makes the content problem smaller. Some of it is uncomfortable: roughly a third of the programme has no written text yet, and the product's single biggest gap is one nobody has started on.

Nothing here has been decided without you. Where a review recommended changing something you authored, it is marked as a recommendation awaiting your approval, with the reasoning shown so you can overturn it. The questions that genuinely need your answer are in a separate, shorter document.

This report is a summary. The complete specifications open in their own pages:

Before anything else, a factual correction to a shared assumption: no application has been built. The project folder contains two empty log files and nothing else — no code, no database, no content loaded, no version history.

The March 2026 developer briefing listed "set up project repo, CI/CD, and design system" as step 3. That step was never performed. The four months since were spent on other projects, and the folder is its unstarted placeholder.

What does exist, sitting on the desktop outside any backup:

• A working Day 1 prototype in React — the welcome screen, check-in sliders, the lesson, an animated box-breathing pacer, reflection, and completion. It runs.
• A phone-frame mockup of the same flow.
• The developer briefing deck from March, which turned out to be a source document nobody had counted.
• A zip containing two of your three original documents.

The prototype is useful, but it is not a foundation

It looks convincing, which is the danger. Its text is written directly into the code, meaning every wording change would require a developer and a release. The architecture in the PRD is deliberately the opposite — content lives as data, so you can edit copy yourself without touching software. Building on the prototype would bake in exactly the problem the design exists to avoid. Its colours, its breathing animation, and its screen sequence are worth keeping; its inner workings are not.

The review began with three documents. It found a fourth, and that changed the interpretation of several apparent contradictions.

The developer briefing deck from 11 March had not been included in the original synthesis. Once counted, a pattern appeared: the business deck, the content framework, and the briefing all date from February–March 2026 and agree with each other. Your July content document is four months newer and revises that position.

What this reframed

The first review read the mismatched module titles as an internal inconsistency inside your July document — an outline disagreeing with its own body. That was wrong. The "outline" names are the March names, confirmed independently by two other documents. Your July document renamed them.

So this is four months of content evolution, not a copy-paste error. Most of the renames are cosmetic. One is not: Module 13 changed from "Meaning & Motivation" to "Understanding Your Emotional Needs" — genuinely different therapeutic content. Since that module's text is missing either way, the decision isn't which title to keep. It's which module to write.

Eleven modules were reviewed screen by screen. This is the part of the project furthest along, and it holds up well under examination — so it is worth being specific about what is there before turning to what isn't.

The July content document specifies, for every session: screen order, screen purpose, exact wording, button labels, option lists, slider endpoints, placeholder examples, and the name of every field the app stores. That is an unusual level of completeness. Most products reach engineering with far less, and the reason the architecture in the PRD could be designed at all is that this document was precise enough to derive it from.

The design is more sophisticated than it first appears

Three things stand out on close reading, and all three shaped the technical architecture:

• The programme escalates in interaction complexity, deliberately. Sessions 1–6 are simple — listen, or write one or two things. From session 7 the interactions get materially harder: multi-select checklists, a background-safe timer, sequential multi-step exercises. A user is taught the habit before being asked to do anything demanding. That is good instructional design and it wasn't accidental.
• Session 10's action plan is genuinely advanced. The user picks their tools, then picks their personal warning signs, then maps each warning sign to a tool — from a dropdown built out of their own earlier answers, including tools they invented themselves. Very few wellbeing products contain an interaction that personalised. It is also the single most technically involved screen in the programme, and it exists because the content asked for it.
• The Toolkit was designed as a persistent object without being named as one. Sessions 10, 11, 13 and 14 all write into it, and session 15's forward plan belongs there too. The July document treats it as somewhere things accumulate and are revisited — which is why the PRD promotes it to a first-class part of the product rather than an exercise output. The recommendation that it should start filling from day one is an extension of your design, not a correction of it.

Craft in the individual sessions

Several sessions contain specific, well-judged therapeutic detail that a generic wellbeing script would not have: session 6 explicitly stating that reframing is not forced positivity, with three questions to guide it; session 8 teaching a three-step method on its own screen before asking anyone to practise it, and stating that a boundary is not a rejection; session 4 normalising the thought before asking for it, with the goal named as noticing, not judging; session 9 separating pause, identify and choose into three discrete steps rather than collapsing them.

These are the parts that make it a programme rather than a collection of exercises, and none of them was changed by any review.

Smaller things found while reading, all fixable

• Sessions 1 and 2 end with the same reflection question word for word. Possibly deliberate repetition, possibly a copy-paste — needs your call.
• Session 4's ending breaks the pattern. Every other session ends with an action or a reminder; session 4 ends by introducing a concept (thoughts are events, not facts). The system now supports that variant — worth knowing it was treated as intentional.
• Session 14 doesn't ask about stress or energy — only about recovery. That's a reasonable choice for that topic, but it means the daily check-in isn't fixed, which is why it was built to vary.
• Session 15 introduces a screen type nothing else uses — the programme feedback screen with a star rating, a recommendation score and a dropdown.
• Four sessions capture something the user never sees again — the priority task (3), the noticed thought (4), the boundary sentence (8), the chosen response (9). Each is asked for thoughtfully and then goes nowhere. This has now been fixed by design: same-day items appear on the home screen, durable ones move into the Toolkit.
• A continuity opportunity you didn't specify: session 6 asks for a stress thought to reframe, and session 4 already captured one. Offering session 4's answer as an editable starting point is an obvious link between the two — but it's your call whether that's helpful or presumptuous.

Modules 1–10 are complete. Modules 11–15 have complete structure, and their prose exists — but it lives somewhere that hasn't been shared.

Modules 12 to 15 contain every screen name, purpose, title, question, option list, button label and stored field. Where the body prose should sit, the document instead carries an instruction: "keep your current text unchanged", "keep the four exercise descriptions exactly as you have written them", and the Finnish "pidä nykyinen tekstisi sellaisenaan". Module 11 is the same for its lesson text and branch scripts.

Those are instructions not to overwrite existing writing — not markers for absent content. "Exactly as you have written them" says plainly that the writing exists. The practical problem is narrower than first reported: that writing is not in the shared Minimente folder. The February content deck contains full prose, including complete audio scripts, but only up to Day 4; the business deck is commercial material; the July content document carries the placeholders. So the passages for Modules 11–15 sit in a working file that hasn't been shared.

This is a retrieval task, not an authoring task — unless the writing turns out not to exist, which only Minni can confirm.

Exactly what sits behind a placeholder

Seventeen passages in total, all in Modules 11–15. Modules 1–10 contain zero.

• Modules 12, 13, 14, 15 — five each: the welcome text, the lesson text, the exercise framing, the reflection text and the daily-action text. Everything else on those screens is present.
• Module 11 — five: the lesson body, the four body-reset descriptions, two branch scripts and the daily action. The document says "keep the four exercise descriptions exactly as you have written them".
• Module 14 — the eight Recovery Wheel categories are present (Rest, Connection, Movement, Nature, Creativity, Learning, Joy & Play, Purpose) but their icons are genuinely corrupted in the export, appearing as garbled characters. That one does need re-supplying.

The Emergency Tools are a separate, real gap

The February deck names seven tools followed by "Etc": breathing reset, grounding, thought-dump journal, body scan, desk stretch, safe place, and progressive relaxation. None has a script in any of the three documents. Two overlap with module exercises that are written, so they can be reused — the rest have never existed as more than names on a list. The prototype confirms it: six tool cards that do nothing when tapped.

This gap is unaffected by the correction above, and it matters because these tools are visible from day one.

What would settle it

Pointing us at the file where Modules 11–15's writing lives. Google Drive version history on the content document is also worth a look, in case an earlier revision carried the full text before it was replaced with the "keep existing" notes.

A design review examined whether the product's shape still made sense, on the basis that nothing is built yet, so structural criticism costs nothing.

Its verdict: the underlying architecture is modern and should not be touched. What is dated is the container around it — a calendar-locked course whose most durable asset appears two-thirds of the way through.

The session is right, the architecture is right, the exclusions are right. The container is the older layer.

An important correction to the framing

The review's headline was "the Toolkit is the product". That was refined in discussion, and the refinement matters for how the content should read: the product is building lifelong skills; the Toolkit is the lasting interface to those skills. The course creates the capability; the Toolkit reinforces it. You want someone finishing the programme thinking "I've learnt how to manage stress", not "I've collected ten tools".

Where the review argued against modernising

• Free-text exercises should stay. Thought reframing, the inner-critic dialogue and the final letter need the person's own words. Replacing them with tappable options would remove the mechanism that makes them work.
• No AI therapist or chat. Not caution for its own sake — an AI responding to distressed employees changes the product's regulatory classification in the EU, and the HR buyer's stated fear is precisely a tool mishandling a distressed employee. Its absence is a selling point.
• No streaks or badges. Recommended as an explicit, permanent rule rather than a quiet omission — game mechanics on a stress product create stress about the stress product.
• No clinical questionnaires. Adding standard depression or anxiety screening instruments would contradict the product's own promise not to diagnose, and would change what it is legally.

A separate research pass asked whether Box Breathing — currently taught on Day 1 — is the right default, and whether different breathing techniques suit different situations.

Five research strands reviewed the scientific literature, clinical practice, performance psychology, comparable products, and personalisation research. The findings challenge the premise of the question.

How strong is the evidence, by claim

Box Breathing lost every direct comparison

It produced higher heart rate and greater perceived exertion than slower breathing; worse cognitive performance than breathing with an extended exhale; and in the only trial run during real working days, a difference of 0.07 points with a confidence interval spanning zero. Its origin is a policing and military training book, not a study. It also contains breath-holds, which are the part of breathing practice most likely to be unsuitable for some people — including during pregnancy and with some heart and respiratory conditions.

The recommendation is to keep it in the library but remove it as the default, replacing Day 1's exercise with a longer-exhale pattern that has no holds. Because this changes a module you authored, it is a recommendation awaiting your decision — and one that should be confirmed by a clinician first, since several of the underlying papers could only be read as abstracts.

The recommended library

• Longer Exhale — in for 4, out for 6, no holds. The new default.
• Cyclic Sighing — 60 seconds, the strongest brief option.
• Resonance Breathing — 5–10 minutes, for recovery.
• Grounded Breathing — eyes open, using an external focus point. Suitable at a desk, and for people for whom turning attention inward is uncomfortable.
• Box Breathing — retained, no longer the default.

Ruled out on evidence and safety: all fast or "energising" breathwork, 4-7-8, alternate-nostril, and any hold longer than four seconds.

This is the most serious finding in the review, and the one nobody has started work on.

All four of your source documents state that Minimente is not suitable for psychological emergencies. None of them describes what the product actually does when someone is in distress. There is no disclaimer flow, no crisis signposting, no escalation path, and no guidance on what happens if someone writes something worrying in a reflection box.

The prototype confirms this isn't merely a documentation oversight — it contains no disclaimer, no crisis information, and no privacy explanation. The gap is real at every level.

What the PRD proposes, subject to your approval and professional sign-off: a plain acknowledgement at sign-up that this is self-help and not a crisis service; a permanent, quietly-placed "Need urgent help?" route showing country-appropriate crisis contacts alongside the employer's occupational health service; a gentle, dismissible prompt if someone's ratings stay very high across several days; and a decision about whether anything anyone types is ever scanned for signs of self-harm — with the recommendation being a purely local check that never transmits or stores anything, so that "no one reads what you write" remains literally true.

Not everything found was a problem. Several things were confirmed, and several questions were closed outright.

Confirmed across every source

• The seven-screen daily session — welcome, check-in, lesson, exercise, reflection, daily action, completion. Four documents and the prototype independently agree. This is the safest structural commitment in the whole project.
• The three personalisation rules — high stress suggests an emergency tool, low energy suggests a body-based exercise. Confirmed in two documents, simple, and honest about what it is.
• The five-part rhythm underlying the session — this is the part that carries the therapeutic evidence.

Closed by the reviews

• Where exercise answers go. Previously they were captured and never seen again; they now surface on the home screen for the day and durable ones move into the Toolkit.
• The employer dashboard now has a defined minimum — enrolment, activation, completion, aggregate stress trend, recommendation score — with the "not enough data" state designed as a visible trust feature rather than an error.
• What happens after the programme ends. The Toolkit, Emergency Tools and "Right now" remain; the product doesn't stop.
• A privacy hole nobody had spotted. The rule requiring at least ten people before showing an aggregate didn't cover time periods — a daily figure in a twelve-person company would let HR infer the reaction to a specific announcement. Reporting is now weekly or coarser.

And everything on the engineering side

A final pass closed all the technical questions, so none of them are waiting on you. In summary:

• What it's built with is decided — a web app that works on phone and desktop from one codebase, with the database, files and email all hosted inside the EU, and the full list of suppliers prepared for the privacy assessment.
• The privacy promise is enforced by the database itself. An employer administrator has no technical route to any individual's records — not a hidden screen, but no path that exists. This is tested automatically on every change, so it cannot be broken by accident later.
• The "at least ten people, weekly or coarser" rule is enforced when figures are written, not when they're displayed — so an aggregate that would break it never gets created in the first place.
• Safety thresholds cannot be changed casually. The release system refuses to publish the safety rules until a clinician has marked them reviewed, and physically blocks anyone from rescaling them arithmetically if the rating scale changes.
• Reminders, offline use, the focus timer, search and the breathing player are all specified and ready to build.

Four things no technical decision can solve

• Reminders on iPhone are structurally weaker than on Android. Apple restricts what web apps can do, and the workaround requires people to add the app to their home screen. A trigger has been set: if iPhone users' reminders are working at less than half the rate of everyone else's after four weeks of the pilot, a proper app-store version gets built.
• Every new way into the app that skips the daily check-in thins the safety signal. The gentle "are you okay?" prompt depends on ratings, and someone who only ever uses the quick-help entry produces none. This is why the always-visible help route matters more than the automatic detection.
• A small pilot company will see an empty dashboard for weeks. That is the anonymity rules working correctly, but the HR buyer needs to be told to expect it, or it will read as the product being broken.
• Content is still the critical path. Settling the technology didn't shorten the writing — it just removed everything that was hiding it.

The technical decisions — what the software is built with, how the database enforces the privacy promise, how notifications and offline use work — are now all settled and written up. None of them needs you, and an engineer can begin as soon as the document is accepted.

What does need you falls into three groups, and only the first is urgent:

1. Four decisions about the shape of the programme. These need one sitting, and no writing. They block the design work.
2. The writing — the missing modules, the Emergency Tool scripts, the Recovery Wheel activities. This runs alongside the build rather than blocking it, because the system is designed to hold unfinished modules safely behind a switch until you mark them ready.
3. The safety work, with legal and clinical input. This should start now, because it is slow and it blocks launch.

Those decisions are set out, in plain language and with the consequences of each option, in the companion document.

The complete research record behind section 07, preserved here with named studies, sample sizes and effect sizes so the reasoning can be checked rather than taken on trust.

Grades used below: strong — multiple systematic reviews or meta-analyses converging, or consistent large trials. Moderate — one good meta-analysis, or at least one well-conducted randomised trial with supporting mechanism data. Weak — small, uncontrolled or single studies, or contested. Insufficient — no protocol-specific evidence found.

• Kasap & Aydin 2025, PLOS ONE 20(11):e0336615 — randomised crossover, n = 40. Box breathing produced higher heart rate than 6 breaths/min (164.7 vs 154.8, p < 0.001) and higher perceived exertion.
• Röttger 2021, Appl Psychophysiol Biofeedback 46(1):19–28 — n = 30, under time pressure and noise. Prolonged exhalation was better for performance; box breathing lowered arousal but produced worse thinking. Directly relevant to a desk product: when you still have to work, the holds cost you.
• Vetter, Kurth & Konigorski 2026, npj Digital Medicine 9:135 — the most product-relevant trial found. N = 76 doctors, in their real working days, over four weeks. Six minutes of box breathing moved daily stress by 0.07 points on a 10-point scale, with the confidence interval crossing zero. Only 10 of 76 were genuine responders — yet 58% felt they had benefited.
• Balban 2023 — box breathing did not beat mindfulness on any measure; only cyclic sighing did.
• At 4-4-4-4 it runs at 3.75 breaths per minute — below the 4.5–6.5 range where the physiology is actually established. It isn't merely unevidenced; it sits outside the window the evidence describes.
• Its origin is a police and military training book, On Combat — not a study. Product copy must never imply it was "developed by research".

The military and tactical literature is genuinely better, and should be represented fairly — but it involves marksmanship and simulated critical incidents, and none of it generalises to a desk.

During panic — and this cuts directly against the original brief. A dismantling trial found breathing retraining added nothing to panic treatment. A component network meta-analysis (Pompoli 2018, Psychological Medicine) found breathing components associated with worse outcomes, though better acceptability. The mechanism concern is that breathing used to neutralise frightening body sensations acts as a safety behaviour, blocking the learning that drives recovery. Barlow & Craske's standard panic manual dropped relaxation training; the Centre for Clinical Interventions' current self-help package contains no breathing module at all, and instead uses breath-holding as deliberate exposure. A respectable counter-position exists — but it teaches patients to breathe less, under clinical supervision with instruments, which is the opposite of what every consumer app says. Both camps agree that "take a deep breath" is wrong advice during panic.

Three further groups need care: people with trauma histories, for whom inward attention, closed eyes and breath-holds are documented dissociation triggers — hence an eyes-open default and an external-anchor option; people with health anxiety, for whom monitoring the body is itself a maintaining factor, so the product must never ask users to check whether it is "working"; and the 17–53% who experience relaxation-induced anxiety, where relaxing paradoxically increases distress. That must be normalised in the copy as ordinary, not treated as the user failing.

These are why the recommended library is small and hold-free by default. Box Breathing, the current Day 1 default, contains two holds per cycle. That is not a footnote — it is the reason the Day 1 exercise is under review.

1. Slow breathing (~5–6 breaths/min) beats fast or hyperventilatory breathing.
2. Five minutes is enough — one trial found no additional benefit at 10, 15 or 20 minutes. Longer is not better.
3. Guided breathing beats doing nothing, and in employees beat a mindfulness comparator for physical recovery.
4. Individual response varies enormously, and average effects during a real working day are near zero — with a minority of genuine responders. Copy must be written around individual variation, not promised benefit.

What cannot be claimed: that technique X is for anxiety and technique Y for focus; that any particular count or ratio targets a particular feeling; or that the recommendation engine itself makes anyone better.

The performance research produced an explicit list of uses with no reliable protocol-specific evidence. Marketing and in-app copy must not imply benefit for any of these:

1. Improving focus or concentration at a desk — one positive lab study at 15 minutes, one null at 5, no meta-analysis, no field study. Specifically, no evidence at all for sessions under 5 minutes improving thinking.
2. Increasing energy safely — nothing safe and evidenced exists.
3. Job interviews — zero studies located.
4. Exams — one non-significant pilot, n = 21.
5. Public speaking — one non-significant trend, and the technique tested actually favoured the control group.
6. Box breathing being better than alternatives for office use — the only head-to-head found the opposite.
7. Reducing cortisol from a short self-guided break — no supporting study.
8. Productivity or work output — the micro-break meta-analysis found performance effects non-significant, and that's for breaks in general.
9. Optimal lead time before a stressful event — never studied.
10. 90-second protocols — no peer-reviewed evidence at that dose.

A separate strand reviewed the competing products — Breathwrk, Othership, Calm, Headspace, Breathly, Balance, Apple's Breathe, and several smaller tools — from vendor sites, store listings, support documentation and user reviews.

It found a market shaped like a barbell, with an empty middle.

Four weaknesses that are all open goals

• Evidence labelling is uniformly poor. The spectrum runs from vague ("informed by modern science") to inflated ("long-term neuroplasticity") to survey-stat marketing ("95% of users report less stress"). No competitor cites studies at the point of the exercise, grades evidence strength, or admits when evidence is preliminary. Regulators have signalled interest in unsubstantiated health-app claims, so honest labelling is both a differentiator and a shield.
• Safety framing is near-absent. Two major products ship hyperventilation-based techniques with minimal in-flow warnings, despite documented risks including fainting and seizure provocation. No competitor markets safety-first defaults as a feature.
• Silence is solved only at the utility tier. Apple offers three levels of haptic pacing; one Android tool has an explicit vibration-only mode. The big platforms bury or omit it. Silent operation is table stakes for office use, and the products best suited to enterprise deliver it worst.
• Accessibility is an afterthought everywhere. No major breathing product documents a reduced-motion alternative to its pacer animation — and expanding, contracting, full-screen motion is a known trigger for vestibular discomfort. This is an open field.

What users complain about — the list of things to design out

Paywalled basics; redesigns that delete people's saved exercises; price; notification nagging; streak pressure; opaque personalisation; billing and support failures. Notably, the most-praised quality across the smaller tools is the absence of monetisation pressure and gamification — which matches this project's own decision not to use streaks or badges.

A fifth strand researched the recommendation question itself. Its most useful contribution is puncturing an assumption the brief rested on.

Which inputs are actually justified, in order

1. How you feel right now — best supported. A single-item question performs as well as a long scale.
2. What you're trying to achieve — goal-setting is robust as a technique, though in one trial only about half of users ever set a goal.
3. What has worked for you before — plausible and theory-aligned, but the evidence is thin. A review of personalisation in mental-health apps concluded it was "scarce and inconclusive". Justified on autonomy and trust grounds, not effectiveness.
4. Favourites — essentially no outcome evidence.
5. Onboarding quizzes — mostly evidence that they hurt. Around 53% of mental-health app users abandon within seven days, and asking for personal information before trust is established is a known drop-off driver.

Explaining the recommendation

Explanations reliably increase trust and willingness to follow a recommendation. But there's an important inversion: explanations that reveal invasive data use actively reduce trust. Because this design only ever references things the user volunteered — "you told us this helped" — it sidesteps that failure entirely. That is a genuine advantage worth stating as a design principle rather than a happy accident.

Honest caveat: no trial was found showing that "because you…" explanations increase completion of wellbeing exercises specifically. The trust finding is solid; the completion claim is extrapolated.

Asking "did this help?"

Two findings shape this. First, burden: once-daily prompting achieves around 91% compliance, versus about 77% at higher frequencies, and being asked to log feelings repeatedly drove rapid abandonment in anxiety apps. Second, bias: people rate the thing they believe the app favours more highly, and self-reported adherence is inflated even without incentives. Expect "did this help?" answers to skew positive.

The mitigations that follow: neutral wording — prefer a before-and-after "how do you feel now?" over "did this help?" — always skippable, never gating progress, sampled rather than asked every single time after the first weeks, and treated as a relative signal within one person rather than an absolute measure.

Repetition or variety?

The evidence genuinely cuts both ways, and the report says so. Habit formation needs repetition in a stable context, and for a skills-based product there's an additional argument for practising one technique until it works under pressure. But identical prompts habituate — in one trial the effect of repeated contextual suggestions decayed to near zero within about four weeks.

The defensible synthesis: keep the behaviour and the cue consistent, rotate the wording, and offer a new technique on a deliberate schedule or when feedback says the current one has stopped helping. Repetition builds the habit; unvarying messaging is what goes stale.